From etinosa4@hotmail.com Tue Mar 1 22:14:52 2005 Received: from mydomain.com (wbs-146-131-188.telkomadsl.co.za [165.146.131.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15558 for ; Tue, 1 Mar 2005 22:14:50 -0500 (EST) From: etinosa4@hotmail.com Message-Id: <200503020314.WAA15558@ietf.org> Received: from smtp1.google.com ([172.69.180.204]) by smtp2.excite.com with Internet Mail Service id 229F4D64; Wed, 02 Mar 2005 13:19:10 -0000 Received: from xmxpita.linksynergy.com ([160.163.5.193]) by broome1.genuity.com with Microsoft SMTPSVC id 066552E0; Wed, 02 Mar 2005 13:19:00 -0000 Received: from esmtp.inreach.com ([197.126.18.216]) by singularity.banelco.com.ar with SMTP id 1BD671E3; Wed, 02 Mar 2005 13:18:50 -0000 Date: Wed, 02 Mar 2005 05:18:50 -0800 To: etinosa4@hotmail.com Subject: PARTNER''' MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear Partner, It is my pleasure to write you this letter on behalf of my colleagues. We have decided to seek a confidential co-operation with you for the execution of a transaction hereunder for the benefit of all parties and hope you will keep it confidential because of the nature of this business. I am the director of Audit and Project Implementation with the Department of Mineral and Energy, two top officials and I have in our possession an overdue payment in US funds. The said funds represent a certain percentage of the total contract value executed on behalf of my department by a foreign contracting firm which we the officials over-invoiced to the amount of Fourteen Million, Five Hundred Thousand United States Dollars only (US$14,500,000.00).The reason of inflating the original value is to divert the excess value to a foreign bank account for our personal use. The actual contract cost has been paid to the original contractor leaving the balance unclaimed. We are seeking your assistance to front as beneficiary of the unclaimed funds as civil servants are not allowed to operate foreign bank account. A formal application for claim to the relevant authority and documentation to present you/company as the beneficiary will be secured on behalf of you/company. I have the authority of my partners involved to propose that should you be willing to assist us in this transaction your share as compensation will be US$3.625M (25%) while my colleagues and I will receive US$9.425M (65%) and the balance of US$1.450M (10%) for taxation and miscellaneous expenses incurred. The business is 100% safe, risk and failure proof provided you treat it with utmost confidentiality and priority as we intend to destroy all the relevant approval documents relating to the project once the payment is released to you/company to avoid any trace to you or us in future. It does not matter whether you/company does contract project as a transfer of powers will be secured in favour of you, also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint us as we intend to conclude the transfer within 14 working days. Kindly reply to my email address stating your complete names, your direct telephone and fax numbers to enable me furnish you with a detailed explanation upon your acceptance of this proposal for effective communication. Thank you for your co-operation. Regards Fredrick Soto private box for reply fredricksoto@mail2world.com From isis-wg-bounces@ietf.org Thu Mar 3 06:07:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07132 for ; Thu, 3 Mar 2005 06:07: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 1D6o9E-0002kO-V6; Thu, 03 Mar 2005 06:05:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6o9C-0002kJ-PO for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 06:05:38 -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 GAA06982 for ; Thu, 3 Mar 2005 06:05:36 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6oAX-00050m-M9 for isis-wg@ietf.org; Thu, 03 Mar 2005 06:07:02 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1109847797296; Thu, 3 Mar 2005 13:03:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 3 Mar 2005 12:08:41 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069EA2@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: IS-IS L1 routers redundancy Thread-Index: AcUf2CrZiz921vXoTmKvQ+H10bJgDw== From: "Yossi Boaron" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [Isis-wg] IS-IS L1 routers redundancy 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="===============1124064330==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1124064330== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51FD8.F9F946AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51FD8.F9F946AC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Assuming the following topology (all the routers configured as IS-IS = level1): R3 |=09 | |=09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | R1 R2 | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | HostA Assumig the following assumptions : 1. R1 and R2 , each one with 2 ethernet interfaces.have the same IS-IS = configuration (system Id , Level , IP address ,, )=20 with one exception the MAC addresses of the interfaces. 2. When R1 is working R2 is not operating (not sending and receiving any = IS-IS PDU) 3. When R2 is working R1 is not operating (not sending and receiving any = IS-IS PDU) 4. I have the ability to synchronize the data plane between R1 and R2 5. HostA is 'speaking' with R3 What would be the best way to achieve redundancy between R1 ,R2 ? Does RFC 3847 will solve this problem (althogh the MAC addresses are = diffrent)? Thanks Yossi ------_=_NextPart_001_01C51FD8.F9F946AC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IS-IS L1 routers redundancy

Hi

Assuming the following = topology  (all the routers configured as IS-IS level1):

         &nbs= p;         R3

                = |      

                |

                = |      

      = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

        |       =        |

        |         &nb= sp;        |

        R1         &n= bsp;    R2

         &nbs= p;   = |            =      |

         |      =        |

         = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

         &nbs= p;       |

             |

           HostA

Assumig the following = assumptions :

1. R1 and  R2  , = each one with 2 ethernet interfaces.have the same IS-IS = configuration  (system Id , Level , IP address ,,  ) =

        with one exception  the MAC addresses of the = interfaces.

2. When R1 is working R2 is = not operating (not sending and receiving any IS-IS PDU)

3. When R2 is working R1 is = not operating (not sending and receiving any IS-IS PDU)

4. I have the ability to = synchronize the data plane between R1 and R2

5. HostA is 'speaking' with = R3



What would be the best way to = achieve redundancy between R1 ,R2 ?

Does RFC 3847 will solve this = problem (althogh the MAC addresses are diffrent)?


Thanks

Yossi







------_=_NextPart_001_01C51FD8.F9F946AC-- --===============1124064330== 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 --===============1124064330==-- From isis-wg-bounces@ietf.org Thu Mar 3 06:09:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07378 for ; Thu, 3 Mar 2005 06:09:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oAg-0002rp-Tp; Thu, 03 Mar 2005 06:07:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oAf-0002rk-Hs for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 06:07:09 -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 GAA07105 for ; Thu, 3 Mar 2005 06:07:07 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6oBz-00052q-Oy for isis-wg@ietf.org; Thu, 03 Mar 2005 06:08:33 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1109847852437; Thu, 3 Mar 2005 13:04:12 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 2 Mar 2005 17:00:49 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069EA1@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: IS-IS adjancency on LAN Thread-Index: AcUfN9GzXRmSpsp7RcCbv0+cKehc5w== From: "Yossi Boaron" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Isis-wg] IS-IS adjancency on LAN 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="===============0148377291==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0148377291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51F38.9F199C14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51F38.9F199C14 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Let's say I have two routers, R1 and R2 to run L1 IS-IS at the same = area, with the following configurations : R1 router=20 =3D=3D=3D=3D=3D=3D=3D=20 interface#1(ethernet) : ip address =3D 172.29.29.14 MAC address =3D = 0x00208f0070fe interface#2(ethernet) : ip address =3D 192.168.17.14 MAC address =3D = 0x00208f0070f1 R2 router=20 =3D=3D=3D=3D=3D=3D=3D IS-IS L1 =20 interface#1(ethernet) : ip address =3D 172.29.29.15 MAC address =3D = 0x00208f0070fc interface#2(ethernet) : ip address =3D 192.161.17.14 MAC address =3D = 0x00208f0070f0 R1 will create L1 adjecency with R2 via interface#1. R2 will create L1 adjecency with R1 via interface#1. Assuming that R1 will start sending the IIH packets on interface#1 with = a new source MAC address ( !=3D 0x00208f0070fe), what would happen to = the adjecency between R2 and R1? Does R2 will change the adjecency state to down and initialize a new = adjecency? Thanks for your attention Yossi ------_=_NextPart_001_01C51F38.9F199C14 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IS-IS adjancency on LAN

Hi

Let's say I have two routers, = R1 and R2 to run L1 IS-IS at the same area,  with the following = configurations :

R1 router

=3D=3D=3D=3D=3D=3D=3D =

interface#1(ethernet)  = :  ip address =3D 172.29.29.14 MAC address =3D = 0x00208f0070fe

interface#2(ethernet) :  = ip address =3D 192.168.17.14 MAC address =3D 0x00208f0070f1


R2 router

=3D=3D=3D=3D=3D=3D=3D

IS-IS L1 

interface#1(ethernet) :  = ip address =3D 172.29.29.15 MAC address =3D 0x00208f0070fc

interface#2(ethernet) :  = ip address =3D 192.161.17.14 MAC address =3D 0x00208f0070f0



R1 will create L1 adjecency = with R2 via interface#1.

R2 will create L1 adjecency = with R1 via interface#1.


Assuming that R1 will start = sending  the IIH packets on interface#1 with a new source MAC = address ( !=3D 0x00208f0070fe), what would happen to the adjecency = between R2 and R1?


Does R2 will change the = adjecency state to down and initialize a new adjecency?

Thanks for your = attention

Yossi

------_=_NextPart_001_01C51F38.9F199C14-- --===============0148377291== 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 --===============0148377291==-- From isis-wg-bounces@ietf.org Thu Mar 3 12:44:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23225 for ; Thu, 3 Mar 2005 12:44: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 1D6uMR-0008M9-Ut; Thu, 03 Mar 2005 12:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uMP-0008Ku-TB for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 12:43: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 MAA23144 for ; Thu, 3 Mar 2005 12:43:38 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uNo-0006yZ-QO for isis-wg@ietf.org; Thu, 03 Mar 2005 12:45:09 -0500 Received: from vpndg ([128.251.10.1] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Mar 2005 09:43:27 -0800 From: "Don Goodspeed" To: "Yossi Boaron" , Subject: RE: [Isis-wg] IS-IS L1 routers redundancy Date: Thu, 3 Mar 2005 09:43:51 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <52F6342A567975489F83368EB54C0D7D069EA2@VRZIL-EX01.il.veraznetworks.com> Importance: Normal X-OriginalArrivalTime: 03 Mar 2005 17:43:27.0871 (UTC) FILETIME=[81C9B0F0:01C52018] X-Spam-Score: 0.3 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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="===============1556536451==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1556536451== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C51FD5.81E21660" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C51FD5.81E21660 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit IS-IS L1 routers redundancyYossi, At a more basic level, VRRP would give you router redundancy for hosts on a network. Don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Yossi Boaron Sent: Thursday, March 03, 2005 2:09 AM To: isis-wg@ietf.org Subject: [Isis-wg] IS-IS L1 routers redundancy Hi Assuming the following topology (all the routers configured as IS-IS level1): R3 | | | ==================== | | | | R1 R2 | | | | ================= | | HostA Assumig the following assumptions : 1. R1 and R2 , each one with 2 ethernet interfaces.have the same IS-IS configuration (system Id , Level , IP address ,, ) with one exception the MAC addresses of the interfaces. 2. When R1 is working R2 is not operating (not sending and receiving any IS-IS PDU) 3. When R2 is working R1 is not operating (not sending and receiving any IS-IS PDU) 4. I have the ability to synchronize the data plane between R1 and R2 5. HostA is 'speaking' with R3 What would be the best way to achieve redundancy between R1 ,R2 ? Does RFC 3847 will solve this problem (althogh the MAC addresses are diffrent)? Thanks Yossi ------=_NextPart_000_003C_01C51FD5.81E21660 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IS-IS L1 routers redundancy
Yossi,
 
At a=20 more basic level, VRRP would give you router redundancy for=20 hosts
on a=20 network.
 
Don
-----Original Message-----
From: = isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org]On Behalf Of Yossi=20 Boaron
Sent: Thursday, March 03, 2005 2:09 AM
To:=20 isis-wg@ietf.org
Subject: [Isis-wg] IS-IS L1 routers = redundancy=20

Hi

Assuming the following = topology  (all=20 the routers configured as IS-IS level1):

          &nbs= p;       =20 R3

               =20 |      

                |

               =20 |      

     =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

        |      =20        |

        |          &nb= sp;      =20 |

        R1          &n= bsp;  =20 R2

          &nbs= p; =20 = |            =     =20 |

         |      =       =20 |

        =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

          &nbs= p;     =20 |

             |

           HostA

Assumig the following = assumptions=20 :

1. R1 and  R2  , = each one with 2=20 ethernet interfaces.have the same IS-IS configuration  (system Id = , Level=20 , IP address ,,  )

        with one exception  the MAC addresses of the=20 interfaces.

2. When R1 is working R2 is = not operating=20 (not sending and receiving any IS-IS PDU)

3. When R2 is working R1 is = not operating=20 (not sending and receiving any IS-IS PDU)

4. I have the ability to = synchronize the=20 data plane between R1 and R2

5. HostA is 'speaking' with=20 R3



What would be the best way to = achieve=20 redundancy between R1 ,R2 ?

Does RFC 3847 will solve this = problem=20 (althogh the MAC addresses are diffrent)?


Thanks

Yossi







------=_NextPart_000_003C_01C51FD5.81E21660-- --===============1556536451== 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 --===============1556536451==-- From isis-wg-bounces@ietf.org Thu Mar 3 12:51:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23924 for ; Thu, 3 Mar 2005 12:51:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uSA-0001Fl-Aw; Thu, 03 Mar 2005 12:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uS8-0001Fb-NZ for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 12:49:36 -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 MAA23653 for ; Thu, 3 Mar 2005 12:49:33 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uTX-00078L-Ms for isis-wg@ietf.org; Thu, 03 Mar 2005 12:51:04 -0500 Received: from vpndg ([128.251.10.1] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Mar 2005 09:49:26 -0800 From: "Don Goodspeed" To: "Yossi Boaron" , Subject: RE: [Isis-wg] IS-IS adjancency on LAN Date: Thu, 3 Mar 2005 09:49:50 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <52F6342A567975489F83368EB54C0D7D069EA1@VRZIL-EX01.il.veraznetworks.com> Importance: Normal X-OriginalArrivalTime: 03 Mar 2005 17:49:27.0076 (UTC) FILETIME=[57E40640:01C52019] X-Spam-Score: 0.9 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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="===============1825479698==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1825479698== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C51FD6.57DB9D40" This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C51FD6.57DB9D40 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit IS-IS adjancency on LANYossi, Some vendors may optimize by declaring a previous adjacency down in this case but the basic thing to do is to form the new adjacency and let the old one expire it's adjacency via hold time expiry. Don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Yossi Boaron Sent: Wednesday, March 02, 2005 7:01 AM To: isis-wg@ietf.org Subject: [Isis-wg] IS-IS adjancency on LAN Hi Let's say I have two routers, R1 and R2 to run L1 IS-IS at the same area, with the following configurations : R1 router ======= interface#1(ethernet) : ip address = 172.29.29.14 MAC address = 0x00208f0070fe interface#2(ethernet) : ip address = 192.168.17.14 MAC address = 0x00208f0070f1 R2 router ======= IS-IS L1 interface#1(ethernet) : ip address = 172.29.29.15 MAC address = 0x00208f0070fc interface#2(ethernet) : ip address = 192.161.17.14 MAC address = 0x00208f0070f0 R1 will create L1 adjecency with R2 via interface#1. R2 will create L1 adjecency with R1 via interface#1. Assuming that R1 will start sending the IIH packets on interface#1 with a new source MAC address ( != 0x00208f0070fe), what would happen to the adjecency between R2 and R1? Does R2 will change the adjecency state to down and initialize a new adjecency? Thanks for your attention Yossi ------=_NextPart_000_0045_01C51FD6.57DB9D40 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IS-IS adjancency on LAN
Yossi,
 
Some=20 vendors may optimize by declaring a previous adjacency = down
in=20 this case but the basic thing to do is to form the new=20 adjacency
and=20 let the old one expire it's adjacency via hold time = expiry.
 
Don
-----Original Message-----
From: = isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org]On Behalf Of Yossi=20 Boaron
Sent: Wednesday, March 02, 2005 7:01 AM
To: = isis-wg@ietf.org
Subject: [Isis-wg] IS-IS adjancency on=20 LAN


Hi

Let's say I have two routers, = R1 and R2 to=20 run L1 IS-IS at the same area,  with the following configurations = :

R1 router

=3D=3D=3D=3D=3D=3D=3D =

interface#1(ethernet)  = :  ip=20 address =3D 172.29.29.14 MAC address =3D 0x00208f0070fe

interface#2(ethernet) :  = ip address =3D=20 192.168.17.14 MAC address =3D 0x00208f0070f1


R2 router

=3D=3D=3D=3D=3D=3D=3D

IS-IS L1 

interface#1(ethernet) :  = ip address =3D=20 172.29.29.15 MAC address =3D 0x00208f0070fc

interface#2(ethernet) :  = ip address =3D=20 192.161.17.14 MAC address =3D 0x00208f0070f0



R1 will create L1 adjecency = with R2 via=20 interface#1.

R2 will create L1 adjecency = with R1 via=20 interface#1.


Assuming that R1 will start = sending =20 the IIH packets on interface#1 with a new source MAC address ( !=3D=20 0x00208f0070fe), what would happen to the adjecency between R2 and=20 R1?


Does R2 will change the = adjecency state to=20 down and initialize a new adjecency?

Thanks for your = attention

Yossi

------=_NextPart_000_0045_01C51FD6.57DB9D40-- --===============1825479698== 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 --===============1825479698==-- From isis-wg-bounces@ietf.org Thu Mar 3 15:43:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13601 for ; Thu, 3 Mar 2005 15:43:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8K-0007h7-2k; Thu, 03 Mar 2005 15:41:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8I-0007gx-M5 for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 15:41:18 -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 PAA13358 for ; Thu, 3 Mar 2005 15:41:16 -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 1D6x9i-0002vu-El for isis-wg@ietf.org; Thu, 03 Mar 2005 15:42:47 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 2538B3DCCAD for ; Thu, 3 Mar 2005 12:41:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <775daa9818278993bbb46ba31a9a1fea@rawdofmt.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Thu, 3 Mar 2005 12:41:09 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Isis-wg] WG Last Call: draft-ietf-isis-caps-00.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 We are starting the WG last call for "IS-IS extensions for advertising router information". Given the upcoming IETF meeting we will extend the last call period to 3 weeks following the IETF meeting. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Mar 3 15:45:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13841 for ; Thu, 3 Mar 2005 15:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8A-0007gY-En; Thu, 03 Mar 2005 15:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x89-0007gO-E1 for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 15:41:09 -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 PAA13337 for ; Thu, 3 Mar 2005 15:41:05 -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 1D6x9X-0002vW-4n for isis-wg@ietf.org; Thu, 03 Mar 2005 15:42:36 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 46AFA3DCCAD for ; Thu, 3 Mar 2005 12:40:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Thu, 3 Mar 2005 12:40:56 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Isis-wg] WG Last Call: draft-ietf-isis-link-attr-00.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 We are starting the WG last call for "Definition of an IS-IS Link Attribute sub-TLV". Given the upcoming IETF meeting we will extend the last call period to 3 weeks following the IETF meeting. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Mar 3 15:46:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13935 for ; Thu, 3 Mar 2005 15:46:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8P-0007hH-C3; Thu, 03 Mar 2005 15:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8O-0007hC-Rg for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 15:41:24 -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 PAA13366 for ; Thu, 3 Mar 2005 15:41:23 -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 1D6x9m-0002vz-Nr for isis-wg@ietf.org; Thu, 03 Mar 2005 15:42:54 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 22BA53DCCAF for ; Thu, 3 Mar 2005 12:41:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Thu, 3 Mar 2005 12:41:13 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Isis-wg] WG Last Call: draft-ietf-isis-admin-tags-03.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 We are starting the WG last call for "A Policy Control Mechanism in IS-IS Using Administrative Tags". Given the upcoming IETF meeting we will extend the last call period to 3 weeks following the IETF meeting. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Mar 3 15:47:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14106 for ; Thu, 3 Mar 2005 15:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8G-0007gn-Pi; Thu, 03 Mar 2005 15:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x8E-0007gd-Pn for isis-wg@megatron.ietf.org; Thu, 03 Mar 2005 15:41: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 PAA13343 for ; Thu, 3 Mar 2005 15:41:13 -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 1D6x9f-0002vp-M5 for isis-wg@ietf.org; Thu, 03 Mar 2005 15:42:43 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 1A5AA3DCCAE for ; Thu, 3 Mar 2005 12:40:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Thu, 3 Mar 2005 12:41:01 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Isis-wg] WG Last Call: draft-ietf-isis-experimental-tlv-04.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 We are starting the WG last call for "TLV for Experimental Use". Given the upcoming IETF meeting we will extend the last call period to 3 weeks following the IETF meeting. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 6 17:36:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03682 for ; Sun, 6 Mar 2005 17:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D84HO-0004hy-Ac; Sun, 06 Mar 2005 17:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D84HL-0004ha-S9 for isis-wg@megatron.ietf.org; Sun, 06 Mar 2005 17:31:16 -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 RAA03199 for ; Sun, 6 Mar 2005 17:31:12 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D84JO-0007om-OT for isis-wg@ietf.org; Sun, 06 Mar 2005 17:33:23 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j26MV59s021447; Sun, 6 Mar 2005 14:31:05 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j26MVBfx020419; Sun, 6 Mar 2005 14:31:11 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j26MVA0A020416; Sun, 6 Mar 2005 14:31:10 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 6 Mar 2005 14:31:10 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG , Jeff Parker In-Reply-To: <20050217014223.GC3480@james> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder Subject: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-18.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 On Thu, 17 Feb 2005, Juergen Schoenwaelder wrote: > I need a MIB doctor for the IS-IS routing protocol MIB which you can > find in . There are some idnits kind > of things the author can hopefully check himself. What seems more > important here is to check the general construction of the MIB module > and of course proper usage of the SMIv2. > > If you have some spare cycles to help, please drop me a note and > indicate when you will be able to work on this MIB module. I have done a somewhat cursory review of the most recent version which was . In general, it appears to be technically sound to the extent that I am able to judge (which is limited because I know little about IS-IS). However, there are a number of small things that probably should be corrected before the document goes to the IESG. The details follow below (organized according to the checklist in Appendix A of draft-ietf-ops-mib-review-guidelines-04.txt). The things most likely to elicit DISCUSS comments from the IESG are probably 6, 10(c), and 10(d). Note: please address replies to the WG mailing list with copies to Bert Wijnen, Juergen Schoenwaelder, and myself. 1.) I-D Boilerplate -- OK 2.) Abstract -- some citations are present, which is not allowed (see http://www.ietf.org/ID-Checklist.html Section 3(1)C). In addition, since this document is intended for the standards track, please change the phrase "an experimental portion" to "a portion" in the 2nd paragraph. 3.) MIB Boilerplate -- present and correct, however, it is customary (and in my opinion preferable) to put it before the narrative that describes the MIB module. So I would suggest reversing the order of Sections 1 and 2 in the draft. 4.) IPR Notice -- OK 5.) References -- there are several problems. (a) the following item [1] "Integrated IS-IS Management Information Base", IETF Draft, March 1994, Chris Gunner. should be removed from the list of normative references since it is not essential to read it in order to implement the MIB module. I suppose it could be moved to the informative references section, but the best thing would probably be to remove it entirely, since it is difficult (at best) to find a copy of draft-ietf-isis-mib-03.txt (http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt exists but the -03 version does not show up there). The original author's efforts are explicitly acknowledged, and that is probably sufficient. (b) for the following [2] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 1992. please change the citation tag from the numeric form to a symbolic one (e.g., [ISO10589]) to match the style of all the other references. You will need to add a citation somewhere in the main body of the text (NOT in the abstract) or else the RFC Editor will complain of a dangling reference. Perhaps the first line of the abstract can be copied (with citations left intact) into the Overview section. (c) [RFC1195] needs to be cited in the text (NOT in the abstract). The remedy suggested aboove in (b) (copying the first line of the abstract into the Overview section with citations left intact) will fix this. (d) the following reference [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. is obsolete and uncited. Please remove it. (e) the following documents [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC3291] Daniele, M.,Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291. have been obsoleted by RFC 3411 and RFC 4001 respectively. Please update these references (and all citations in the text) accordingly. (f) I see that normative references do exist for all MIB modules from which things are imported and that appropriate citations exist. I also see that the references required by the boilerplate are present and accounted for. That is good. However, the REFERENCE clauses in the MIB module point to RFC 2973 and to RFC 3373, neither of which is present in the reference list. I think that these should be among the normative references and that they need to be mentioned in the discussion in the overview section. Also, there are numerous REFERENCE clauses that point to GDMO objects, and it would be good to have some text in the Overview saying where those objects are defined, with references to the appropriate documents. In http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt I see the following text: The objects are mainly derived from the GDMO definitions in ISO 10589 and from the GDMO definitions in ISO 10733 [5]. with this reference: [5]"Information Technology - Telocommunications and information exchange between systems - Elements of Management Information Related to OSI Network Layer Standards", International Standard 10733 (ISO submission copy), September 1992. and I wonder if something along those lines would be appropriate here. 6.) Security Considerations Section -- I see that the part on writeable objects states that "there are very few writable attributes that do not have negative side effects on network operations." It might be better to say "all writeable attributes have the potential to disrupt network operations if improperly modified and may require protection against unauthorized write access." Also, are there readable objects (objects with an access of greater than not-accessible) that could reveal sensitive information if read by unauthorized parties? If so, that needs to be discussed. If not, that needs to be explicitly stated. See Section 3.4 of the MIB review guidelines (draft-ietf-ops-mib-review-guidelines-04.txt) for discussion. 7.) IANA Considerations Section -- content is correct, although it is customary for this section to appear after the MIB module. 8.) Copyright Notices -- OK 9.) Other issues (e.g., from http://www.ietf.org/ID-Checklist.html) that are not covered elsewhere: (a) missing punctuation in Overview section: OLD The IS-IS MIB defines the following objects NEW The IS-IS MIB defines the following objects: 10.) Technical content -- review of actual technical content for compliance with : (a) MIB compilation using smilint -- The program smilint 0.4.3, as of Mon Jan 17 19:25:32 2005 has been used to process your request as follows: smilint -m -s -e -l 6 mailbody mailbody:59: [1] {object-identifier-unknown} unknown object identifier label `mib-2' mailbody:6: [5] {import-unused} warning: identifier `experimental' imported from module `SNMPv2-SMI' is never used The problem is that the draft still IMPORTS 'experimental' instead of 'mib-2'. Proposed remedy: OLD: MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter32, experimental, NOTIFICATION-TYPE NEW: MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, mib-2 Note: the same results issue from SMICng. (b) In the MODULE-IDENTITY DESCRIPTION clause I think that jparker at world dot std dot edu needs to be changed to jparker at world dot std dot com. (I am not sure if the RFC Editor will let it remain in this form, but I guess it's worth a try :) (c) As noted in Section 4.6.4 of the MIB review guidelines, it is REQUIRED that each read-create table specify what happens to dynamically-created rows after an agent restart, and when a RowStatus column is present, it is necessary to specify whether modifications are allowed when the status column is 'active'. I don't thing that these requirements have been met. (d) I see that every InetAddress object has a SYNTAX value of InetAddress (SIZE(4|16)) and that every InetAddressPrefixLength object has a SYNTAX value of InetAddressPrefixLength (0..128), but the corresponding InetAddressType objects have a SYNTAX value of InetAddressType with no constraint but with a proviso in the DESCRIPTION clause that "[a]n implementation is only required to support IPv4 and IPv6 addresses." If the intent is to forever limit support to IPv4 and IPv6, which is the effect that the present SYNTAX refinements on the InetAddress and InetAddressPrefixLength objects have, then then it would be better to use a SYNTAX refinement in the InetAddressType objects to express that, rather than using text in the DESCRIPTION clause that is more appropriate in a compliance statement. Please note, however, that it is strongly preferred (at least in the MIB Doctor community) to have _no_ constraints in the definitions of objects of this type, and instead to put OBJECT clauses in the relevant compliance statements or, for inaccessible INDEX objects, text in the compliance statements' DESCRIPTION clauses. For a usage example in a similar application see draft-ietf-ipv6-rfc2096-update-07.txt, which defines the inetCidrRouteTable. Note that the lack of constraints on INDEX objects of type InetAddress leads to definitions that could, in principle, exceed the 128 sub-ID length on SNMP object names; as recommended in the MIB review guidelines Section 4.6.6, draft-ietf-ipv6-rfc2096-update-07.txt includes text in the inetCidrRouteEntry DESCRIPTION clause that spells out the limitations. Note that the DESCRIPTION clause of every object of type InetAddress or InetAddressPrefixLength is REQUIRED to specify which InetAddressType object that provides the context in which is it interpreted, and none of the definitions in the module follow that rule. That needs to be corrected even if it is decided not to remove the constraints on the objects. (e) The DESCRIPTION clauses of isisSummAddressType, isisRedistributeAddrType, isisISAdjIPAddrType, isisIPRADestType, and isisIPRANextHopType include the sentence "[a]n implementation is only required to support IPv4 and IPv6 addresses." Similarly, the DESCRIPTION clauses of isisSummAddrExistState, isisRedistributeAddrExistState, isisCircExistState, isisRAExistState, and isisIPRAExistState include the sentence "[s]upport for createAndWait and notInService is not required." Since it is describing what an agent is required to do, rather than what makes "protocol sense" for the object to support, that type of language belongs in an OBJECT clause in a compliance statement, not in the object definition itself. (f) The DESCRIPTION clauses of isisManAreaAddr, isisSummAddressType, isisSummAddress, isisRedistributeAddrType, isisRedistributeAddrAddress, isisCircIndex, and isisRAIndex contain the sentence "[t]his object follows the index behavior" or an equivalent phrase. Similarly, the DESCRIPTION clauses of isisManAreaAddrExistState, isisSummAddrExistState, isisRedistributeAddrExistState, and isisCircExistState include the sentence "[t]his object follows the Row Status behavior." Finally, the DESCRIPTION clauses of isisCircAdminState and isisRAAdminState include the sentence "[t]his object follows the AdminState behavior" or an equivalent phrase. I'm not quite sure what these sentences are supposed to mean. If the intent is to say (respectively) "this is an INDEX object" or "this is a RowStatus object" or "this is an AdminState object" then there is no value in having them, since the INDEX clause of the enclosing table or the SYNTAX clause of the object already tells me what I need to know. If the intent is something else then it needs to be defined (as are the behaviors ResettingTimer, ReplaceOnlyWhileDisabled, and ManualOrAutomatic). (g) I infer from the DESCRIPTION of the following object that it is set by a manager and then decremented each second by the agent until it becomes zero: isisSysLevelSetOverloadUntil OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) UNITS "Seconds until clearing manually set Overload Bit" MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is non-zero, the overload bit is set at this level when the isisSysAdminState variable goes to state 'on' for this Intermediate System. The overload bit remains set for isisSysLevelSetOverloadUntil seconds. When isisSysLevelSetOverloadUntil seconds have elapsed, the overload flag remains set if the implementation has run out of memory, or if it is set manually using the isisSysLevelSetOverload object." ::= { isisSysLevelEntry 6 } If that is the case, the SYNTAX value needs to be changed to include zero (e.g., Unsigned32 with no range constraint). (h) The DESCRIPTION clause of isisNextCircIndex does not seem to be entirely consistent with the DESCRIPTION clause of the IndexIntegerNextFree TC in RFC 3289. Here is a suggestion: OLD: isisNextCircIndex OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assign values to isisCircIndex as described in 'Textual Conventions for SNMPv2'. The network manager reads this object, and then writes the value back as the isisCircIndex in a SET that creates a new instance of isisCircEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the object is incremented, and the new isisCircuit is created according to the manager's directions." NEW: isisNextCircIndex OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assist a management application in creating new rows in the isisCircTable. If it is possible to create a new instance of isisCircEntry, then this object will contain a non-zero value that is not in use as the index of any row in the isisCircTable. The network manager reads the value of this object and then (if the value value read is non-zero) attempts to create the corresponding instance of isisCircEntry. If the set request fails ith the code 'inconsistentValue', the the process must be repeated; if the set request succeeds, then the agent will change value of this object according to an implementation-specific algorithm." (i) From the fact that isisCircIfIndex has a SYNTAX value of InterfaceIndex (not InterfaceIndexOrZero) I infer that there there is always an ifTable entry associated with a circuit. That being the case, neither isisCircIndex nor isisCircIfIndex is strictly necessary -- one could use ifIndex as itself as the index, thereby eliminating the need for both of these objects. However, the existing design is acceptable. (j) It seems to me that for at least some interface types the object isisCircIfSubSelector will be irrelevant. If that is true, then it would be good to specify that the object gets some distinguished value (e.g., 0 or -1) if it is not used. (k) The commentary just prior to the definition of isisRATable contains the following line: -- The Reachable Address Group is optional. I would recommend that this statement be removed. As a general rule, any statements on what is optional to implement and what is required should be in the compliance statements alone and should not be included in object descriptions or in the ASN.1 comments that surround them. (l) The DESCRIPTION clauses of isisRAIndex, isisIPRADestType, isisIPRADest, and isisIPRADestPrefixLen say that they follow he ManualOrAutomatic behavior. However, that behavior says the object is read-write or read-only, and so cannot apply to inaccessible index objects such as these (it can apply to the corresponding RowStatus object, which allows the row to be created or destroyed if appropriate). (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: "The 8 byte LSP ID, consisting of the SystemID, Circuit ID, and Fragment Number." Maybe this is a stupid question, but shouldn't the isisLSPSummaryTable be concerning itself with entire reassembled link state PDUs and not individual fragments thereof? If so, perhaps the DESCRIPTION clause should be revised. (If this were IPv4, and I were describing a complete, reassembled IP PDU, I would specify that Fragment Offset=0 and MF=0, and I would also stipulate that the checksum is what would have been computed for the complete datagram prior to fragmentation. But perhaps those considerations don't apply here.) (n) In the isisLSPTLVTable, the checksum and sequence number are provided for each TLV, but are properties of the LSP than contains them, or so I infer. If that is so, it might be good to change the DESCRIPTION clause of isisLSPTLVSeq as from: "The 16 bit Fletcher Checksum." to: "The 16 bit Fletcher Checksum for this LSP." Note that isisLSPTLVSeq already has similar language. (o) It would be less confusing to readers like me if the ASN.1 comment before the start of the notification definitions were changed from: -- Type definitions to: -- Notification definitions (p) I see the following language in several of the notification definitions: This should be an edge-triggered notification. We should not send a second notification about PDUs received from the same circuit. This seems to imply that no more than one such notification per circuit per agent reboot will be generated. What if the condition is persistent? Shouldn't there be additional notifications? One possible alternative that might be worth considering is allowing no more than one notification per circuit per interval of duration T (where T may be a design parameter that is fixed or the value of some read/write object). This is suggested in Sec. 4.7 of the MIB review guidelines. (q) In a related vein: are all of the notifications that lack explicit throttling by their nature generated at a sufficiently low rate that they will not cause an excess of notifications? A cursory reading suggests that this is so, but the author should verify that this is the case. (r) Be aware that as written the compliance statements isisCompliance and isisAdvancedCompliance do not provide for read-only implementations of the MIB module. No changes need to be made if that is the intent, but the author should verify that this is the case. This concludes my review of . Regards, Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 6 18:56:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12930 for ; Sun, 6 Mar 2005 18:56: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 1D85a4-000655-3a; Sun, 06 Mar 2005 18:54:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D85a2-00064m-Au for isis-wg@megatron.ietf.org; Sun, 06 Mar 2005 18:54:38 -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 SAA12752 for ; Sun, 6 Mar 2005 18:54:34 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D85c6-0001Ow-S0 for isis-wg@ietf.org; Sun, 06 Mar 2005 18:56:47 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Sun, 6 Mar 2005 18:54:28 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 6 Mar 2005 18:54:27 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 06 Mar 2005 18:54:27 -0500 Subject: Re: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-18.txt From: "Parker, Jeff" To: "C. M. Heard" , ISIS WG , Jeff Parker Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Mar 2005 23:54:27.0991 (UTC) FILETIME=[D517B270:01C522A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder 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 - I accept (almost) all of your comments, and I'm you didn't get to (z) in your list of points. One comment on (m). IS-IS does not depend on IP, and it does it's own fragmentation at the packet source. Think "PDU" when you read "Fragment". I could use the 10589 term, "LSP number field", rather than "Fragment Number", but that term seems more ambiguous to me, as the LSP is full of numbers. This fragmentation scheme leads to a great deal of confusion when routers have a different value for the MTU, which gave rise to a number of Notifications about OriginatingBufferSize and the like. - jeff > (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: > "The 8 byte LSP ID, consisting of the SystemID, > Circuit ID, and Fragment Number." > Maybe this is a stupid question, but shouldn't the > isisLSPSummaryTable be concerning itself with entire reassembled > link state PDUs and not individual fragments thereof? If so, > perhaps the DESCRIPTION clause should be revised. (If this were > IPv4, and I were describing a complete, reassembled IP PDU, I > would specify that Fragment Offset=0 and MF=0, and I would also > stipulate that the checksum is what would have been computed for > the complete datagram prior to fragmentation. But perhaps those > considerations don't apply here.) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 6 20:49:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22266 for ; Sun, 6 Mar 2005 20:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87Lb-0008Dc-Hb; Sun, 06 Mar 2005 20:47:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87La-0008DX-77 for isis-wg@megatron.ietf.org; Sun, 06 Mar 2005 20:47:50 -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 UAA22134 for ; Sun, 6 Mar 2005 20:47:47 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D87Ne-0003zw-J3 for isis-wg@ietf.org; Sun, 06 Mar 2005 20:49:59 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j271lV9s018962; Sun, 6 Mar 2005 17:47:31 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j271lb2B023755; Sun, 6 Mar 2005 17:47:37 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j271la5g023750; Sun, 6 Mar 2005 17:47:36 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 6 Mar 2005 17:47:36 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeff Parker Subject: Re: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-18.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder , ISIS WG 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 suspected that the question I raised in 10(m) below might just be a result of my limited understanding of IS-IS. If the WG is happy with the object definition as it stands, then so am I. Regards, Heard On Sun, 6 Mar 2005, Parker, Jeff wrote: > Mike - > I accept (almost) all of your comments, and I'm you didn't > get to (z) in your list of points. One comment on (m). > > IS-IS does not depend on IP, and it does it's own > fragmentation at the packet source. Think "PDU" when you read > "Fragment". > I could use the 10589 term, "LSP number field", rather than > "Fragment Number", but that term seems more ambiguous to me, as > the LSP is full of numbers. > > This fragmentation scheme leads to a great deal of confusion > when routers have a different value for the MTU, which gave rise > to a number of Notifications about OriginatingBufferSize and the > like. > > - jeff > > > (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: > > "The 8 byte LSP ID, consisting of the SystemID, > > Circuit ID, and Fragment Number." > > Maybe this is a stupid question, but shouldn't the > > isisLSPSummaryTable be concerning itself with entire reassembled > > link state PDUs and not individual fragments thereof? If so, > > perhaps the DESCRIPTION clause should be revised. (If this were > > IPv4, and I were describing a complete, reassembled IP PDU, I > > would specify that Fragment Offset=0 and MF=0, and I would also > > stipulate that the checksum is what would have been computed for > > the complete datagram prior to fragmentation. But perhaps those > > considerations don't apply here.) > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Mar 8 06:56:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14372 for ; Tue, 8 Mar 2005 06:56:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8dGw-0003M8-6V; Tue, 08 Mar 2005 06:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8dGu-0003M3-Tk for isis-wg@megatron.ietf.org; Tue, 08 Mar 2005 06:53:08 -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 GAA14256 for ; Tue, 8 Mar 2005 06:53:05 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8dJG-0002Di-EV for isis-wg@ietf.org; Tue, 08 Mar 2005 06:55:37 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 8 Mar 2005 11:52:48 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7069BC82C@duke.datcon.co.uk> Thread-Topic: capabilities TLV issues Thread-Index: AcUjOmaI4MeHbXh4SPijqS8P1UA/FgAA9tPw From: "Jonathan Harrison" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Isis-wg] Comments on draft-ietf-isis-caps-00.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: , Content-Type: multipart/mixed; boundary="===============1161261598==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1161261598== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C523D5.594D1FC0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C523D5.594D1FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JP, Rahul, Naiming, I've had a look at draft-ietf-isis-caps-00.txt. Overall, it looks good, = but I have a few comments and suggestions below. 1) The draft identifies the originator of the capabilities TLV using = router ID. This is quite unusual for an IS-IS TLV, which normally use = the IS-IS system ID, and so the draft probably needs some additional = clarification as to why the router ID is used instead. In particular, = it is worth noting that an IS-IS node is not required to advertise a = router ID unless it supports traffic engineering. If the aim of the draft is to add the ability to advertise a generic = capability using the IS-IS protocol, I think it makes more sense to use = the system ID to identify the advertising router. (In this case, if an = individual capability or set of capabilities is TE-related and requires = an associated router ID or IP address, then this should be included in = the appropriate sub-TLV.) 2) The draft states that a system should not use capability TLVs unless = the advertiser of the LSP containing the TLV is currently reachable by a = path at the appropriate level. It would be good to explain the reason = for this requirement. It feels to me that this is an overly strict requirement, that may = restrict the type of information carried (and which will certainly make = implementation of the draft much harder). While it may be the case that = some capabilities should only be used if the node advertising the = capability is reachable, I don't think we should insist that this is the = case for all capabilities.=20 My preference would be to remove this restriction. Instead, the = description of each capability sub-TLV should indicate whether = reachability is a requirement for accepting that sub-TLV.=20 3) The draft touches on the issue of having multiple capabilities TLVs = with different contents, and the possibility of a TLV moving from one = LSP fragment to another - it is definitely a good thing to have the = draft consider this! There is one thing I would suggest that might make = such considerations simpler... The draft states the following: "Where a receiving system has two copies = of a capabilities TLV from the same system which have different settings = for a given attribute, the procedure used to choose which copy shall be = used is undefined." At a minimum, it would be good to explicitly say = that such a receiving system should choose one of the copies of the TLV = to use (instead of, for example, discarding both). If possible, it = would be good to suggest some procedure for choosing between two copies = of the TLV, to ensure that behavior is consistent across the domain. Another question this raises for an implementer is this - how does a = router know if TLV A and TLV B are two copies of the same TLV, rather = than being different TLVs? If the capabilities TLV were to include an = extra byte to identify a particular instance of the TLV, then I think = this would all become much simpler. (This identifier would also reduce = the amount of checking required in order to prevent the leaking of = multiple copies of the same TLV from level 2 into level 1.) 4) The second paragraph of section 4 has the phrase "...at least one = L1/L2 Router in every area of the domain MUST support the Router = CAPABILITY TLV." I think this comes out a bit stronger than the = intended meaning! Would it be better to change the sentence to read as follows "In a = network where Router CAPABILITY TLVs with domain-wide scope originated = by L1 Routers are required to be flooded across the entire domain, then = it is necessary for at least one L1/L2 Router in every area of the = domain to support the Router CAPABILITY TLV." It may also be worth noting that this is an operational requirement, = rather than being something required for an implementation of the = protocol. =20 Let me know what you think! Thanks, Jon ------_=_NextPart_001_01C523D5.594D1FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-isis-caps-00.txt

JP, Rahul, Naiming,

I've had a look at = draft-ietf-isis-caps-00.txt.  Overall, it looks good, but I have a = few comments and suggestions below.

1) The draft identifies the originator = of the capabilities TLV using router ID.  This is quite unusual for = an IS-IS TLV, which normally use the IS-IS system ID, and so the draft = probably needs some additional clarification as to why the router ID is = used instead.  In particular, it is worth noting that an IS-IS node = is not required to advertise a router ID unless it supports traffic = engineering.

If the aim of the draft is to add the = ability to advertise a generic capability using the IS-IS protocol, I = think it makes more sense to use the system ID to identify the = advertising router.  (In this case, if an individual capability or = set of capabilities is TE-related and requires an associated router ID = or IP address, then this should be included in the appropriate = sub-TLV.)

2) The draft states that a system = should not use capability TLVs unless the advertiser of the LSP = containing the TLV is currently reachable by a path at the appropriate = level.  It would be good to explain the reason for this = requirement.

It feels to me that this is an overly = strict requirement, that may restrict the type of information carried = (and which will certainly make implementation of the draft much = harder).  While it may be the case that some capabilities should = only be used if the node advertising the capability is reachable, I = don't think we should insist that this is the case for all capabilities. =

My preference would be to remove this = restriction.  Instead, the description of each capability sub-TLV = should indicate whether reachability is a requirement for accepting that = sub-TLV.

3) The draft touches on the issue of = having multiple capabilities TLVs with different contents, and the = possibility of a TLV moving from one LSP fragment to another - it is = definitely a good thing to have the draft consider this!  There is = one thing I would suggest that might make such considerations = simpler...

The draft states the following: = "Where a receiving system has two copies of a capabilities TLV from = the same system which have different settings for a given attribute, the = procedure used to choose which copy shall be used is = undefined."  At a minimum, it would be good to explicitly say = that such a receiving system should choose one of the copies of the TLV = to use (instead of, for example, discarding both).  If possible, it = would be good to suggest some procedure for choosing between two copies = of the TLV, to ensure that behavior is consistent across the = domain.

Another question this raises for an = implementer is this - how does a router know if TLV A and TLV B are two = copies of the same TLV, rather than being different TLVs?  If the = capabilities TLV were to include an extra byte to identify a particular = instance of the TLV, then I think this would all become much = simpler.  (This identifier would also reduce the amount of checking = required in order to prevent the leaking of multiple copies of the same = TLV from level 2 into level 1.)

4)  The second paragraph of = section 4 has the phrase "...at least one L1/L2 Router in every = area of the domain MUST support the Router CAPABILITY TLV."  I = think this comes out a bit stronger than the intended = meaning!

Would it be better to change the = sentence to read as follows "In a network where Router CAPABILITY = TLVs with domain-wide scope originated by L1 Routers are required to be = flooded across the entire domain, then it is necessary for at least one = L1/L2 Router in every area of the domain to support the Router = CAPABILITY TLV."

It may also be worth noting that this = is an operational requirement, rather than being something required for = an implementation of the protocol. 

Let me know what you think!
Thanks,
Jon

------_=_NextPart_001_01C523D5.594D1FC0-- --===============1161261598== 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 --===============1161261598==-- From isis-wg-bounces@ietf.org Tue Mar 8 16:30:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21968 for ; Tue, 8 Mar 2005 16:30: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 1D8mGb-0000qB-2l; Tue, 08 Mar 2005 16:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mGX-0000pg-VX for isis-wg@megatron.ietf.org; Tue, 08 Mar 2005 16:29: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 QAA21799 for ; Tue, 8 Mar 2005 16:29:19 -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 1D8mIz-0001cF-VY for isis-wg@ietf.org; Tue, 08 Mar 2005 16:31:54 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 13:43:14 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28LT9q8019616; Tue, 8 Mar 2005 13:29:09 -0800 (PST) Received: from ginsberg-w2k01.cisco.com (spandya-w2k.cisco.com [128.107.163.50]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYW19852; Tue, 8 Mar 2005 13:29:08 -0800 (PST) Message-Id: <4.3.2.7.2.20050308124021.021b96e0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Mar 2005 13:29:08 -0800 To: "Jonathan Harrison" From: Les Ginsberg Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt In-Reply-To: <37701240971DD31193970000F6CCB9F7069BC82C@duke.datcon.co.uk > Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: isis-wg@ietf.org, rahul@juniper.net, jvasseur@cisco.com 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="===============0143878509==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0143878509== Content-Type: multipart/alternative; boundary="=====================_8368913==_.ALT" --=====================_8368913==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jonathan - At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote: >JP, Rahul, Naiming, > >I've had a look at draft-ietf-isis-caps-00.txt. Overall, it looks good, >but I have a few comments and suggestions below. > >1) The draft identifies the originator of the capabilities TLV using >router ID. This is quite unusual for an IS-IS TLV, which normally use the >IS-IS system ID, and so the draft probably needs some additional >clarification as to why the router ID is used instead. In particular, it >is worth noting that an IS-IS node is not required to advertise a router >ID unless it supports traffic engineering. > >If the aim of the draft is to add the ability to advertise a generic >capability using the IS-IS protocol, I think it makes more sense to use >the system ID to identify the advertising router. (In this case, if an >individual capability or set of capabilities is TE-related and requires an >associated router ID or IP address, then this should be included in the >appropriate sub-TLV.) There is one potential problem with using system ID. Technically, L1 system IDs are only required to be unique within the area. It is therefore possible for two L1 routers in different areas to have the same system ID, which would lead to ambiguity if both routers advertised capabilities TLVs which have domain wide scope. This problem is unlikely to occur in the real world, but it is possible and legal under the protocol definition. >2) The draft states that a system should not use capability TLVs unless >the advertiser of the LSP containing the TLV is currently reachable by a >path at the appropriate level. It would be good to explain the reason for >this requirement. Sure. Here's an example. If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, they will flood it into the L2 domain. Now suppose the L1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out. Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information - and they have no reliable way to choose (more on that below). By making sure that T stops leaking A's information, we remove the possibility that other routers will use stale information from A. Basically, we are affording the same protection to the capabilities information that comes naturally to IP reachability TLVs i.e. don't use information from unreachable systems. >It feels to me that this is an overly strict requirement, that may >restrict the type of information carried (and which will certainly make >implementation of the draft much harder). While it may be the case that >some capabilities should only be used if the node advertising the >capability is reachable, I don't think we should insist that this is the >case for all capabilities. > >My preference would be to remove this restriction. Instead, the >description of each capability sub-TLV should indicate whether >reachability is a requirement for accepting that sub-TLV. > >3) The draft touches on the issue of having multiple capabilities TLVs >with different contents, and the possibility of a TLV moving from one LSP >fragment to another - it is definitely a good thing to have the draft >consider this! There is one thing I would suggest that might make such >considerations simpler... > >The draft states the following: "Where a receiving system has two copies >of a capabilities TLV from the same system which have different settings >for a given attribute, the procedure used to choose which copy shall be >used is undefined." At a minimum, it would be good to explicitly say that >such a receiving system should choose one of the copies of the TLV to use >(instead of, for example, discarding both). If possible, it would be good >to suggest some procedure for choosing between two copies of the TLV, to >ensure that behavior is consistent across the domain. This was discussed at some length during the writing of the draft. Although it would be nice to have a deterministic way of deciding which of two copies of a TLV are newer, in order to do so we would have to introduce the equivalent of LSP sequence numbers per TLV along with all of the attendant issues of dealing with sequence # rollover. This type of solution was considered too heavyweight to deal with a problem which only occurs as a transient condition. Other simpler schemes are possible (e.g. use the higher numbered LSP, or use the copy most recently received) but as the LSP database is distributed, one can encounter scenarios where different routers make different decisions at different moments in time, so we haven't accomplished much. It should be noted this problem not unique to capabilities TLVs, The same issues arise for any TLV type (e.g. IS-neighbor) when the sending system moves the TLV from one LSP fragment to another. The draft describes recommended practices to minimize the occurrence of the transient disruption and the duration of such disruption if it is impossible to avoid moving a TLV (as it sometimes can be). >Another question this raises for an implementer is this - how does a >router know if TLV A and TLV B are two copies of the same TLV, rather than >being different TLVs? It is necessary to compare the contents. In particular, for a given source, the set of sub-TLVs advertised must be compared. Where two copies of the same sub-TLV are provided, then there is duplicate information. > If the capabilities TLV were to include an extra byte to identify a > particular instance of the TLV, then I think this would all become much > simpler. (This identifier would also reduce the amount of checking > required in order to prevent the leaking of multiple copies of the same > TLV from level 2 into level 1.) > >4) The second paragraph of section 4 has the phrase "...at least one >L1/L2 Router in every area of the domain MUST support the Router >CAPABILITY TLV." I think this comes out a bit stronger than the intended >meaning! > >Would it be better to change the sentence to read as follows "In a network >where Router CAPABILITY TLVs with domain-wide scope originated by L1 >Routers are required to be flooded across the entire domain, then it is >necessary for at least one L1/L2 Router in every area of the domain to >support the Router CAPABILITY TLV." I don't have a problem with your wording or the current wording. :-) >It may also be worth noting that this is an operational requirement, >rather than being something required for an implementation of the protocol. I thought that was self-evident...maybe not? Les >Let me know what you think! >Thanks, >Jon >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_8368913==_.ALT Content-Type: text/html; charset="us-ascii" Jonathan -

At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote:

JP, Rahul, Naiming,

I've had a look at draft-ietf-isis-caps-00.txt.  Overall, it looks good, but I have a few comments and suggestions below.

1) The draft identifies the originator of the capabilities TLV using router ID.  This is quite unusual for an IS-IS TLV, which normally use the IS-IS system ID, and so the draft probably needs some additional clarification as to why the router ID is used instead.  In particular, it is worth noting that an IS-IS node is not required to advertise a router ID unless it supports traffic engineering.

If the aim of the draft is to add the ability to advertise a generic capability using the IS-IS protocol, I think it makes more sense to use the system ID to identify the advertising router.  (In this case, if an individual capability or set of capabilities is TE-related and requires an associated router ID or IP address, then this should be included in the appropriate sub-TLV.)

There is one potential problem with using system ID. Technically, L1 system IDs are only required to be unique within the area. It is therefore possible for two L1 routers in different areas to have the same system ID, which would lead to ambiguity if both routers advertised capabilities TLVs which have domain wide scope. This problem is unlikely to occur in the real world, but it is possible and legal under the protocol definition.

2) The draft states that a system should not use capability TLVs unless the advertiser of the LSP containing the TLV is currently reachable by a path at the appropriate level.  It would be good to explain the reason for this requirement.

Sure. Here's an example.

If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, they will flood it into the L2 domain. Now suppose the L1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.

Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information - and they have no reliable way to choose (more on that below). By making sure that T stops leaking A's information, we remove the possibility that other routers will use stale information from A.

Basically, we are affording the same protection to the capabilities information that comes naturally to IP reachability TLVs i.e. don't use information from unreachable systems.

It feels to me that this is an overly strict requirement, that may restrict the type of information carried (and which will certainly make implementation of the draft much harder).  While it may be the case that some capabilities should only be used if the node advertising the capability is reachable, I don't think we should insist that this is the case for all capabilities.

My preference would be to remove this restriction.  Instead, the description of each capability sub-TLV should indicate whether reachability is a requirement for accepting that sub-TLV.

3) The draft touches on the issue of having multiple capabilities TLVs with different contents, and the possibility of a TLV moving from one LSP fragment to another - it is definitely a good thing to have the draft consider this!  There is one thing I would suggest that might make such considerations simpler...

The draft states the following: "Where a receiving system has two copies of a capabilities TLV from the same system which have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined."  At a minimum, it would be good to explicitly say that such a receiving system should choose one of the copies of the TLV to use (instead of, for example, discarding both).  If possible, it would be good to suggest some procedure for choosing between two copies of the TLV, to ensure that behavior is consistent across the domain.

This was discussed at some length during the writing of the draft. Although it would be nice to have a deterministic way of deciding which of two copies of a TLV are newer, in order to do so we would have to introduce the equivalent of LSP sequence numbers per TLV along with all of the attendant issues of dealing with sequence # rollover. This type of solution was considered too heavyweight to deal with a problem which only occurs as a transient condition.

Other simpler schemes are possible (e.g. use the higher numbered LSP, or use the copy most recently received) but as the LSP database is distributed, one can encounter scenarios where different routers make different decisions at different moments in time, so we haven't accomplished much.

It should be noted this problem not unique to capabilities TLVs, The same issues arise for any TLV type (e.g. IS-neighbor) when the sending system moves the TLV from one LSP fragment to another. The draft describes recommended practices to minimize the occurrence of the transient disruption and the duration of such disruption if it is impossible to avoid moving a TLV (as it sometimes can be).

Another question this raises for an implementer is this - how does a router know if TLV A and TLV B are two copies of the same TLV, rather than being different TLVs?

It is necessary to compare the contents. In particular, for a given source, the set of sub-TLVs advertised must be compared. Where two copies of the same sub-TLV are provided, then there is duplicate information.

 If the capabilities TLV were to include an extra byte to identify a particular instance of the TLV, then I think this would all become much simpler.  (This identifier would also reduce the amount of checking required in order to prevent the leaking of multiple copies of the same TLV from level 2 into level 1.)

4)  The second paragraph of section 4 has the phrase "...at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV."  I think this comes out a bit stronger than the intended meaning!

Would it be better to change the sentence to read as follows "In a network where Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers are required to be flooded across the entire domain, then it is necessary for at least one L1/L2 Router in every area of the domain to support the Router CAPABILITY TLV."

I don't have a problem with your wording or the current wording. :-)

It may also be worth noting that this is an operational requirement, rather than being something required for an implementation of the protocol. 

I thought that was self-evident...maybe not?

   Les


Let me know what you think!
Thanks,
Jon
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_8368913==_.ALT-- --===============0143878509== 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 --===============0143878509==-- From isis-wg-bounces@ietf.org Tue Mar 8 16:57:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24325 for ; Tue, 8 Mar 2005 16:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mgF-0003pe-T3; Tue, 08 Mar 2005 16:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mgE-0003pT-9v for isis-wg@megatron.ietf.org; Tue, 08 Mar 2005 16:55:54 -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 QAA24227 for ; Tue, 8 Mar 2005 16:55:51 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mie-0002BA-S5 for isis-wg@ietf.org; Tue, 08 Mar 2005 16:58:27 -0500 Received: from dgoodspeedpc ([172.22.184.130] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 13:55:34 -0800 From: "Don Goodspeed" To: "'Les Ginsberg'" , "'Jonathan Harrison'" Subject: RE: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt Date: Tue, 8 Mar 2005 13:55:36 -0800 Message-ID: <004601c52429$8ff95b70$f703a8c0@eng.timetra.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <4.3.2.7.2.20050308124021.021b96e0@mira-sjc5-3.cisco.com> Importance: Normal X-OriginalArrivalTime: 08 Mar 2005 21:55:34.0603 (UTC) FILETIME=[8E1691B0:01C52429] X-Spam-Score: 0.1 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Cc: jvasseur@cisco.com, isis-wg@ietf.org, rahul@juniper.net 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="===============1342470502==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1342470502== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C523E6.81D61B70" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C523E6.81D61B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Les, On the router ID issue, according to RFC 3784, if one does not implement traffic engineering, then advertisement of the router ID TLV is optional. Since these boxes can never send capability TLVs (by the current definition), do we need to add text that overrides the optional language in RFC 3784? The section I refer to is section 5: If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP.Cheers,Don-----Original Message-----From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Les GinsbergSent: Tuesday, March 08, 2005 1:29 PMTo: Jonathan HarrisonCc: isis-wg@ietf.org; rahul@juniper.net; jvasseur@cisco.comSubject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txtJonathan - At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote: JP, Rahul, Naiming, I've had a look at draft-ietf-isis-caps-00.txt. Overall, it looks good, but I have a few comments and suggestions below. 1) The draft identifies the originator of the capabilities TLV using router ID. This is quite unusual for an IS-IS TLV, which normally use the IS-IS system ID, and so the draft probably needs some additional clarification as to why the router ID is used instead. In particular, it is worth noting that an IS-IS node is not required to advertise a router ID unless it supports traffic engineering. If the aim of the draft is to add the ability to advertise a generic capability using the IS-IS protocol, I think it makes more sense to use the system ID to identify the advertising router. (In this case, if an individual capability or set of capabilities is TE-related and requires an associated router ID or IP address, then this should be included in the appropriate sub-TLV.) There is one potential problem with using system ID. Technically, L1 system IDs are only required to be unique within the area. It is therefore possible for two L1 routers in different areas to have the same system ID, which would lead to ambiguity if both routers advertised capabilities TLVs which have domain wide scope. This problem is unlikely to occur in the real world, but it is possible and legal under the protocol definition. 2) The draft states that a system should not use capability TLVs unless the advertiser of the LSP containing the TLV is currently reachable by a path at the appropriate level. It would be good to explain the reason for this requirement. Sure. Here's an example. If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, they will flood it into the L2 domain. Now suppose the L1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out. Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information - and they have no reliable way to choose (more on that below). By making sure that T stops leaking A's information, we remove the possibility that other routers will use stale information from A. Basically, we are affording the same protection to the capabilities information that comes naturally to IP reachability TLVs i.e. don't use information from unreachable systems. It feels to me that this is an overly strict requirement, that may restrict the type of information carried (and which will certainly make implementation of the draft much harder). While it may be the case that some capabilities should only be used if the node advertising the capability is reachable, I don't think we should insist that this is the case for all capabilities. My preference would be to remove this restriction. Instead, the description of each capability sub-TLV should indicate whether reachability is a requirement for accepting that sub-TLV. 3) The draft touches on the issue of having multiple capabilities TLVs with different contents, and the possibility of a TLV moving from one LSP fragment to another - it is definitely a good thing to have the draft consider this! There is one thing I would suggest that might make such considerations simpler... The draft states the following: "Where a receiving system has two copies of a capabilities TLV from the same system which have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined." At a minimum, it would be good to explicitly say that such a receiving system should choose one of the copies of the TLV to use (instead of, for example, discarding both). If possible, it would be good to suggest some procedure for choosing between two copies of the TLV, to ensure that behavior is consistent across the domain. This was discussed at some length during the writing of the draft. Although it would be nice to have a deterministic way of deciding which of two copies of a TLV are newer, in order to do so we would have to introduce the equivalent of LSP sequence numbers per TLV along with all of the attendant issues of dealing with sequence # rollover. This type of solution was considered too heavyweight to deal with a problem which only occurs as a transient condition. Other simpler schemes are possible (e.g. use the higher numbered LSP, or use the copy most recently received) but as the LSP database is distributed, one can encounter scenarios where different routers make different decisions at different moments in time, so we haven't accomplished much. It should be noted this problem not unique to capabilities TLVs, The same issues arise for any TLV type (e.g. IS-neighbor) when the sending system moves the TLV from one LSP fragment to another. The draft describes recommended practices to minimize the occurrence of the transient disruption and the duration of such disruption if it is impossible to avoid moving a TLV (as it sometimes can be). Another question this raises for an implementer is this - how does a router know if TLV A and TLV B are two copies of the same TLV, rather than being different TLVs? It is necessary to compare the contents. In particular, for a given source, the set of sub-TLVs advertised must be compared. Where two copies of the same sub-TLV are provided, then there is duplicate information. If the capabilities TLV were to include an extra byte to identify a particular instance of the TLV, then I think this would all become much simpler. (This identifier would also reduce the amount of checking required in order to prevent the leaking of multiple copies of the same TLV from level 2 into level 1.) 4) The second paragraph of section 4 has the phrase "...at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV." I think this comes out a bit stronger than the intended meaning! Would it be better to change the sentence to read as follows "In a network where Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers are required to be flooded across the entire domain, then it is necessary for at least one L1/L2 Router in every area of the domain to support the Router CAPABILITY TLV." I don't have a problem with your wording or the current wording. :-) It may also be worth noting that this is an operational requirement, rather than being something required for an implementation of the protocol. I thought that was self-evident...maybe not? Les Let me know what you think! Thanks, Jon _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------=_NextPart_000_0047_01C523E6.81D61B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Les,
 
On the=20 router ID issue, according to RFC 3784, if one does not=20 implement
traffic engineering, then advertisement of the router ID TLV is = optional.
 
Since these boxes can never send capability TLVs (by the = current=20 definition),
do we=20 need to add text that overrides the optional language in RFC=20 3784?
 
The=20 section I refer to is section 5:
   If a router does not implement =
traffic engineering, it MAY add or
   omit the Traffic Engineering router ID TLV.  If a router implements
   traffic engineering, it MUST include this TLV in its =
LSP.
Cheers,
Don
 
-----Original Message-----
From: =
isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf =
Of Les Ginsberg
Sent: Tuesday, March 08, 2005 1:29 =
PM
To: Jonathan Harrison
Cc: isis-wg@ietf.org; =
rahul@juniper.net; jvasseur@cisco.com
Subject: Re: [Isis-wg] =
Comments on draft-ietf-isis-caps-00.txt

Jonathan -

At = 11:52 AM=20 3/8/2005 +0000, Jonathan Harrison wrote:

JP, Rahul, = Naiming,=20

I've had a look at = draft-ietf-isis-caps-00.txt. =20 Overall, it looks good, but I have a few comments and suggestions=20 below.

1) The draft identifies the = originator of=20 the capabilities TLV using router ID.  This is quite unusual = for an=20 IS-IS TLV, which normally use the IS-IS system ID, and so the draft = probably=20 needs some additional clarification as to why the router ID is used=20 instead.  In particular, it is worth noting that an IS-IS node = is not=20 required to advertise a router ID unless it supports traffic=20 engineering.

If the aim of the draft is = to add=20 the ability to advertise a generic capability using the IS-IS = protocol, I=20 think it makes more sense to use the system ID to identify the = advertising=20 router.  (In this case, if an individual capability or set of=20 capabilities is TE-related and requires an associated router ID or = IP=20 address, then this should be included in the appropriate=20 sub-TLV.)

There is one potential problem = with using=20 system ID. Technically, L1 system IDs are only required to be unique = within=20 the area. It is therefore possible for two L1 routers in different = areas to=20 have the same system ID, which would lead to ambiguity if both routers = advertised capabilities TLVs which have domain wide scope. This = problem is=20 unlikely to occur in the real world, but it is possible and legal = under the=20 protocol definition.

2) The draft states = that a=20 system should not use capability TLVs unless the advertiser of the = LSP=20 containing the TLV is currently reachable by a path at the = appropriate=20 level.  It would be good to explain the reason for this=20 requirement.

Sure. Here's an = example.

If L1=20 router A generates a CAP TLV and floods it to L1/L2 routers S and T, = they will=20 flood it into the L2 domain. Now suppose the L1 area partitions, such = that A=20 and S are in one partition and T is in another. IP routing will still = continue=20 to work, but if A now issues a revised version of the CAP TLV, or = decides to=20 stop advertising it, S will follow suit, but T will continue to = advertise the=20 old version until the LSP times out.

Routers in other areas = have to=20 choose whether to trust T's copy of A's capabilities or S's copy of = A's=20 information - and they have no reliable way to choose (more on that = below). By=20 making sure that T stops leaking A's information, we remove the = possibility=20 that other routers will use stale information from = A.

Basically, we are=20 affording the same protection to the capabilities information that = comes=20 naturally to IP reachability TLVs i.e. don't use information from = unreachable=20 systems.

It feels to me that = this is an=20 overly strict requirement, that may restrict the type of information = carried=20 (and which will certainly make implementation of the draft much=20 harder).  While it may be the case that some capabilities = should only=20 be used if the node advertising the capability is reachable, I don't = think=20 we should insist that this is the case for all capabilities.=20

My preference would be to remove this=20 restriction.  Instead, the description of each capability = sub-TLV=20 should indicate whether reachability is a requirement for accepting = that=20 sub-TLV.

3) The draft touches on the = issue of=20 having multiple capabilities TLVs with different contents, and the=20 possibility of a TLV moving from one LSP fragment to another - it is = definitely a good thing to have the draft consider this!  There = is one=20 thing I would suggest that might make such considerations=20 simpler...

The draft states the = following: "Where=20 a receiving system has two copies of a capabilities TLV from the = same system=20 which have different settings for a given attribute, the procedure = used to=20 choose which copy shall be used is undefined."  At a minimum, = it would=20 be good to explicitly say that such a receiving system should choose = one of=20 the copies of the TLV to use (instead of, for example, discarding=20 both).  If possible, it would be good to suggest some procedure = for=20 choosing between two copies of the TLV, to ensure that behavior is=20 consistent across the domain.

This was = discussed at=20 some length during the writing of the draft. Although it would be nice = to have=20 a deterministic way of deciding which of two copies of a TLV are = newer, in=20 order to do so we would have to introduce the equivalent of LSP = sequence=20 numbers per TLV along with all of the attendant issues of dealing with = sequence # rollover. This type of solution was considered too = heavyweight to=20 deal with a problem which only occurs as a transient = condition.

Other=20 simpler schemes are possible (e.g. use the higher numbered LSP, or use = the=20 copy most recently received) but as the LSP database is distributed, = one can=20 encounter scenarios where different routers make different decisions = at=20 different moments in time, so we haven't accomplished much.

It = should=20 be noted this problem not unique to capabilities TLVs, The same issues = arise=20 for any TLV type (e.g. IS-neighbor) when the sending system moves the = TLV from=20 one LSP fragment to another. The draft describes recommended practices = to=20 minimize the occurrence of the transient disruption and the duration = of such=20 disruption if it is impossible to avoid moving a TLV (as it sometimes = can=20 be).

Another question = this raises=20 for an implementer is this - how does a router know if TLV A and TLV = B are=20 two copies of the same TLV, rather than being different TLVs?=20

It is necessary to compare the contents. In=20 particular, for a given source, the set of sub-TLVs advertised must be = compared. Where two copies of the same sub-TLV are provided, then = there is=20 duplicate information.

 If the = capabilities TLV=20 were to include an extra byte to identify a particular instance of = the TLV,=20 then I think this would all become much simpler.  (This = identifier=20 would also reduce the amount of checking required in order to = prevent the=20 leaking of multiple copies of the same TLV from level 2 into level=20 1.)

4)  The second paragraph of = section 4=20 has the phrase "...at least one L1/L2 Router in every area of the = domain=20 MUST support the Router CAPABILITY TLV."  I think this comes = out a bit=20 stronger than the intended meaning!

Would it be=20 better to change the sentence to read as follows "In a network where = Router=20 CAPABILITY TLVs with domain-wide scope originated by L1 Routers are = required=20 to be flooded across the entire domain, then it is necessary for at = least=20 one L1/L2 Router in every area of the domain to support the Router=20 CAPABILITY TLV."

I don't have a problem = with your=20 wording or the current wording. :-)

It may also be = worth noting=20 that this is an operational requirement, rather than being something = required for an implementation of the protocol. =20

I thought that was self-evident...maybe=20 not?

   Les


Let me know what = you=20 think!
Thanks,
Jon=20
_______________________________________________
Isis-wg = mailing=20 list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
------=_NextPart_000_0047_01C523E6.81D61B70-- --===============1342470502== 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 --===============1342470502==-- From isis-wg-bounces@ietf.org Tue Mar 8 17:11:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25329 for ; Tue, 8 Mar 2005 17:11:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8msN-0005WH-3F; Tue, 08 Mar 2005 17:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8msL-0005W8-Ak for isis-wg@megatron.ietf.org; Tue, 08 Mar 2005 17:08:25 -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 RAA25038 for ; Tue, 8 Mar 2005 17:08:22 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mun-0002QG-Se for isis-wg@ietf.org; Tue, 08 Mar 2005 17:10:58 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2005 14:23:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,148,1107763200"; d="scan'208,217"; a="618372641:sNHT133650022" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28M87q8015751; Tue, 8 Mar 2005 14:08:08 -0800 (PST) Received: from ginsberg-w2k01.cisco.com (spandya-w2k.cisco.com [128.107.163.50]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYW24927; Tue, 8 Mar 2005 14:08:10 -0800 (PST) Message-Id: <4.3.2.7.2.20050308140133.0223ed48@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Mar 2005 14:08:10 -0800 To: From: Les Ginsberg Subject: RE: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt In-Reply-To: <004601c52429$8ff95b70$f703a8c0@eng.timetra.com> References: <4.3.2.7.2.20050308124021.021b96e0@mira-sjc5-3.cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: jvasseur@cisco.com, isis-wg@ietf.org, rahul@juniper.net, "'Jonathan Harrison'" 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="===============0580226234==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0580226234== Content-Type: multipart/alternative; boundary="=====================_10710731==_.ALT" --=====================_10710731==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:55 PM 3/8/2005 -0800, Don Goodspeed wrote: >Les, > >On the router ID issue, according to RFC 3784, if one does not implement >traffic engineering, then advertisement of the router ID TLV is optional. > >Since these boxes can never send capability TLVs (by the current definition), >do we need to add text that overrides the optional language in RFC 3784? > Don - It doesn't seem to me that we are conflict with RFC 3784. What probably needs to be said is that a router which sends capability TLVs SHOULD (MUST?) also send a router ID TLV. I think that sort of thing is probably assumed because the examples of the usage of the capabilities TLV are TE related - but it does seem better if it were explicitly stated since we are not restricting the use of the capabilities TLV to TE only. Les >The section I refer to is section 5: > > If a router does not implement traffic engineering, it MAY add or > omit the Traffic Engineering router ID TLV. If a router implements > traffic engineering, it MUST include this TLV in its LSP. >Cheers, > >Don > > -----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf >Of Les Ginsberg >Sent: Tuesday, March 08, 2005 1:29 PM >To: Jonathan Harrison >Cc: isis-wg@ietf.org; rahul@juniper.net; jvasseur@cisco.com >Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt > >Jonathan - > >At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote: > >>JP, Rahul, Naiming, >> >>I've had a look at draft-ietf-isis-caps-00.txt. Overall, it looks good, >>but I have a few comments and suggestions below. >>1) The draft identifies the originator of the capabilities TLV using >>router ID. This is quite unusual for an IS-IS TLV, which normally use >>the IS-IS system ID, and so the draft probably needs some additional >>clarification as to why the router ID is used instead. In particular, it >>is worth noting that an IS-IS node is not required to advertise a router >>ID unless it supports traffic engineering. >>If the aim of the draft is to add the ability to advertise a generic >>capability using the IS-IS protocol, I think it makes more sense to use >>the system ID to identify the advertising router. (In this case, if an >>individual capability or set of capabilities is TE-related and requires >>an associated router ID or IP address, then this should be included in >>the appropriate sub-TLV.) >There is one potential problem with using system ID. Technically, L1 >system IDs are only required to be unique within the area. It is therefore >possible for two L1 routers in different areas to have the same system ID, >which would lead to ambiguity if both routers advertised capabilities TLVs >which have domain wide scope. This problem is unlikely to occur in the >real world, but it is possible and legal under the protocol definition. > >>2) The draft states that a system should not use capability TLVs unless >>the advertiser of the LSP containing the TLV is currently reachable by a >>path at the appropriate level. It would be good to explain the reason >>for this requirement. >Sure. Here's an example. > >If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, >they will flood it into the L2 domain. Now suppose the L1 area partitions, >such that A and S are in one partition and T is in another. IP routing >will still continue to work, but if A now issues a revised version of the >CAP TLV, or decides to stop advertising it, S will follow suit, but T will >continue to advertise the old version until the LSP times out. > >Routers in other areas have to choose whether to trust T's copy of A's >capabilities or S's copy of A's information - and they have no reliable >way to choose (more on that below). By making sure that T stops leaking >A's information, we remove the possibility that other routers will use >stale information from A. > >Basically, we are affording the same protection to the capabilities >information that comes naturally to IP reachability TLVs i.e. don't use >information from unreachable systems. > >>It feels to me that this is an overly strict requirement, that may >>restrict the type of information carried (and which will certainly make >>implementation of the draft much harder). While it may be the case that >>some capabilities should only be used if the node advertising the >>capability is reachable, I don't think we should insist that this is the >>case for all capabilities. >>My preference would be to remove this restriction. Instead, the >>description of each capability sub-TLV should indicate whether >>reachability is a requirement for accepting that sub-TLV. >>3) The draft touches on the issue of having multiple capabilities TLVs >>with different contents, and the possibility of a TLV moving from one LSP >>fragment to another - it is definitely a good thing to have the draft >>consider this! There is one thing I would suggest that might make such >>considerations simpler... >>The draft states the following: "Where a receiving system has two copies >>of a capabilities TLV from the same system which have different settings >>for a given attribute, the procedure used to choose which copy shall be >>used is undefined." At a minimum, it would be good to explicitly say >>that such a receiving system should choose one of the copies of the TLV >>to use (instead of, for example, discarding both). If possible, it would >>be good to suggest some procedure for choosing between two copies of the >>TLV, to ensure that behavior is consistent across the domain. >This was discussed at some length during the writing of the draft. >Although it would be nice to have a deterministic way of deciding which of >two copies of a TLV are newer, in order to do so we would have to >introduce the equivalent of LSP sequence numbers per TLV along with all of >the attendant issues of dealing with sequence # rollover. This type of >solution was considered too heavyweight to deal with a problem which only >occurs as a transient condition. > >Other simpler schemes are possible (e.g. use the higher numbered LSP, or >use the copy most recently received) but as the LSP database is >distributed, one can encounter scenarios where different routers make >different decisions at different moments in time, so we haven't >accomplished much. > >It should be noted this problem not unique to capabilities TLVs, The same >issues arise for any TLV type (e.g. IS-neighbor) when the sending system >moves the TLV from one LSP fragment to another. The draft describes >recommended practices to minimize the occurrence of the transient >disruption and the duration of such disruption if it is impossible to >avoid moving a TLV (as it sometimes can be). > >>Another question this raises for an implementer is this - how does a >>router know if TLV A and TLV B are two copies of the same TLV, rather >>than being different TLVs? >It is necessary to compare the contents. In particular, for a given >source, the set of sub-TLVs advertised must be compared. Where two copies >of the same sub-TLV are provided, then there is duplicate information. > >> If the capabilities TLV were to include an extra byte to identify a >> particular instance of the TLV, then I think this would all become much >> simpler. (This identifier would also reduce the amount of checking >> required in order to prevent the leaking of multiple copies of the same >> TLV from level 2 into level 1.) >>4) The second paragraph of section 4 has the phrase "...at least one >>L1/L2 Router in every area of the domain MUST support the Router >>CAPABILITY TLV." I think this comes out a bit stronger than the intended >>meaning! >>Would it be better to change the sentence to read as follows "In a >>network where Router CAPABILITY TLVs with domain-wide scope originated by >>L1 Routers are required to be flooded across the entire domain, then it >>is necessary for at least one L1/L2 Router in every area of the domain to >>support the Router CAPABILITY TLV." >I don't have a problem with your wording or the current wording. :-) > >>It may also be worth noting that this is an operational requirement, >>rather than being something required for an implementation of the protocol. >I thought that was self-evident...maybe not? > > Les > > > >>Let me know what you think! >>Thanks, >>Jon >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_10710731==_.ALT Content-Type: text/html; charset="us-ascii" At 01:55 PM 3/8/2005 -0800, Don Goodspeed wrote:
Les,
 
On the router ID issue, according to RFC 3784, if one does not implement
traffic engineering, then advertisement of the router ID TLV is optional.
 
Since these boxes can never send capability TLVs (by the current definition),
do we need to add text that overrides the optional language in RFC 3784?
 

Don -

It doesn't seem to me that we are conflict with RFC 3784. What probably needs to be said is that a router which sends capability TLVs SHOULD (MUST?) also send a router ID TLV.

I think that sort of thing is probably assumed because the examples of the usage of the capabilities TLV are TE related - but it does seem better if it were explicitly stated since we are not restricting the use of the capabilities TLV to TE only.

   Les

The section I refer to is section 5:

   If a router does not implement traffic
engineering, it MAY add or
   omit the Traffic Engineering router ID TLV.  If a
router implements
   traffic engineering, it MUST include this TLV in its
LSP.

Cheers,


Don

 
-----Original Message-----
From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Les Ginsberg
Sent: Tuesday, March 08, 2005 1:29 PM
To: Jonathan Harrison
Cc: isis-wg@ietf.org; rahul@juniper.net; jvasseur@cisco.com
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt
Jonathan -

At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote:

JP, Rahul, Naiming,

I've had a look at draft-ietf-isis-caps-00.txt.  Overall, it looks good, but I have a few comments and suggestions below.
1) The draft identifies the originator of the capabilities TLV using router ID.  This is quite unusual for an IS-IS TLV, which normally use the IS-IS system ID, and so the draft probably needs some additional clarification as to why the router ID is used instead.  In particular, it is worth noting that an IS-IS node is not required to advertise a router ID unless it supports traffic engineering.
If the aim of the draft is to add the ability to advertise a generic capability using the IS-IS protocol, I think it makes more sense to use the system ID to identify the advertising router.  (In this case, if an individual capability or set of capabilities is TE-related and requires an associated router ID or IP address, then this should be included in the appropriate sub-TLV.)
There is one potential problem with using system ID. Technically, L1 system IDs are only required to be unique within the area. It is therefore possible for two L1 routers in different areas to have the same system ID, which would lead to ambiguity if both routers advertised capabilities TLVs which have domain wide scope. This problem is unlikely to occur in the real world, but it is possible and legal under the protocol definition.

2) The draft states that a system should not use capability TLVs unless the advertiser of the LSP containing the TLV is currently reachable by a path at the appropriate level.  It would be good to explain the reason for this requirement.
Sure. Here's an example.

If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, they will flood it into the L2 domain. Now suppose the L1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.

Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information - and they have no reliable way to choose (more on that below). By making sure that T stops leaking A's information, we remove the possibility that other routers will use stale information from A.

Basically, we are affording the same protection to the capabilities information that comes naturally to IP reachability TLVs i.e. don't use information from unreachable systems.

It feels to me that this is an overly strict requirement, that may restrict the type of information carried (and which will certainly make implementation of the draft much harder).  While it may be the case that some capabilities should only be used if the node advertising the capability is reachable, I don't think we should insist that this is the case for all capabilities.
My preference would be to remove this restriction.  Instead, the description of each capability sub-TLV should indicate whether reachability is a requirement for accepting that sub-TLV.
3) The draft touches on the issue of having multiple capabilities TLVs with different contents, and the possibility of a TLV moving from one LSP fragment to another - it is definitely a good thing to have the draft consider this!  There is one thing I would suggest that might make such considerations simpler...
The draft states the following: "Where a receiving system has two copies of a capabilities TLV from the same system which have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined."  At a minimum, it would be good to explicitly say that such a receiving system should choose one of the copies of the TLV to use (instead of, for example, discarding both).  If possible, it would be good to suggest some procedure for choosing between two copies of the TLV, to ensure that behavior is consistent across the domain.
This was discussed at some length during the writing of the draft. Although it would be nice to have a deterministic way of deciding which of two copies of a TLV are newer, in order to do so we would have to introduce the equivalent of LSP sequence numbers per TLV along with all of the attendant issues of dealing with sequence # rollover. This type of solution was considered too heavyweight to deal with a problem which only occurs as a transient condition.

Other simpler schemes are possible (e.g. use the higher numbered LSP, or use the copy most recently received) but as the LSP database is distributed, one can encounter scenarios where different routers make different decisions at different moments in time, so we haven't accomplished much.

It should be noted this problem not unique to capabilities TLVs, The same issues arise for any TLV type (e.g. IS-neighbor) when the sending system moves the TLV from one LSP fragment to another. The draft describes recommended practices to minimize the occurrence of the transient disruption and the duration of such disruption if it is impossible to avoid moving a TLV (as it sometimes can be).

Another question this raises for an implementer is this - how does a router know if TLV A and TLV B are two copies of the same TLV, rather than being different TLVs?
It is necessary to compare the contents. In particular, for a given source, the set of sub-TLVs advertised must be compared. Where two copies of the same sub-TLV are provided, then there is duplicate information.

 If the capabilities TLV were to include an extra byte to identify a particular instance of the TLV, then I think this would all become much simpler.  (This identifier would also reduce the amount of checking required in order to prevent the leaking of multiple copies of the same TLV from level 2 into level 1.)
4)  The second paragraph of section 4 has the phrase "...at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV."  I think this comes out a bit stronger than the intended meaning!
Would it be better to change the sentence to read as follows "In a network where Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers are required to be flooded across the entire domain, then it is necessary for at least one L1/L2 Router in every area of the domain to support the Router CAPABILITY TLV."
I don't have a problem with your wording or the current wording. :-)

It may also be worth noting that this is an operational requirement, rather than being something required for an implementation of the protocol. 
I thought that was self-evident...maybe not?

   Les



Let me know what you think!
Thanks,
Jon
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_10710731==_.ALT-- --===============0580226234== 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 --===============0580226234==-- From isis-wg-bounces@ietf.org Wed Mar 9 00:01:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27775 for ; Wed, 9 Mar 2005 00:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tJ3-0003rp-24; Wed, 09 Mar 2005 00:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tJ1-0003rk-86 for isis-wg@megatron.ietf.org; Wed, 09 Mar 2005 00:00: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 AAA27701 for ; Wed, 9 Mar 2005 00:00:20 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8tLX-00020B-Tg for isis-wg@ietf.org; Wed, 09 Mar 2005 00:03:00 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 21:00:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2950ATM010447; Tue, 8 Mar 2005 21:00:11 -0800 (PST) Message-ID: <422E82EA.3050609@cisco.com> Date: Tue, 08 Mar 2005 21:00:26 -0800 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Harrison References: <37701240971DD31193970000F6CCB9F7069BC82C@duke.datcon.co.uk> In-Reply-To: <37701240971DD31193970000F6CCB9F7069BC82C@duke.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org, rahul@juniper.net, jvasseur@cisco.com Subject: [Isis-wg] Re: Comments on draft-ietf-isis-caps-00.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 Jonathan, thanks for the comments, see some reply inline, Jonathan Harrison wrote: > JP, Rahul, Naiming, > > I've had a look at draft-ietf-isis-caps-00.txt. Overall, it looks good, > but I have a few comments and suggestions below. > > 1) The draft identifies the originator of the capabilities TLV using > router ID. This is quite unusual for an IS-IS TLV, which normally use > the IS-IS system ID, and so the draft probably needs some additional > clarification as to why the router ID is used instead. In particular, > it is worth noting that an IS-IS node is not required to advertise a > router ID unless it supports traffic engineering. > > If the aim of the draft is to add the ability to advertise a generic > capability using the IS-IS protocol, I think it makes more sense to use > the system ID to identify the advertising router. (In this case, if an > individual capability or set of capabilities is TE-related and requires > an associated router ID or IP address, then this should be included in > the appropriate sub-TLV.) If the receiving router is in the same area as the originating one, then it knows the systemID of the sender from the LSPs, there is no need to attach a systemID again. If they are in different areas, then systemID does not help, since you may not know how to get there. With RouterID, you may have a route to this router which owns this ID, it makes the service selection decision much easier, be it a TE or something else. Yes, the routerID TLV is optional, but the implementation can always generating the routerID when it advertises the CAP TLV, also sometimes, have a route to the routerID is enough too. Applications also don't want to know if they are using OSPF or IS-IS, routerID is more generic. > > 2) The draft states that a system should not use capability TLVs unless > the advertiser of the LSP containing the TLV is currently reachable by a > path at the appropriate level. It would be good to explain the reason > for this requirement. > > It feels to me that this is an overly strict requirement, that may > restrict the type of information carried (and which will certainly make > implementation of the draft much harder). While it may be the case that > some capabilities should only be used if the node advertising the > capability is reachable, I don't think we should insist that this is the > case for all capabilities. > > My preference would be to remove this restriction. Instead, the > description of each capability sub-TLV should indicate whether > reachability is a requirement for accepting that sub-TLV. > On one hand it seems a little strict requirement, on the other hand, can you trust the information from a router you can not even reach? can you think of a specific appliction which works better if this requirement is relaxed? also note that, we don't want to use IS-IS or OSPF as a general information carrier. > 3) The draft touches on the issue of having multiple capabilities TLVs > with different contents, and the possibility of a TLV moving from one > LSP fragment to another - it is definitely a good thing to have the > draft consider this! There is one thing I would suggest that might make > such considerations simpler... > > The draft states the following: "Where a receiving system has two copies > of a capabilities TLV from the same system which have different settings > for a given attribute, the procedure used to choose which copy shall be > used is undefined." At a minimum, it would be good to explicitly say > that such a receiving system should choose one of the copies of the TLV > to use (instead of, for example, discarding both). If possible, it > would be good to suggest some procedure for choosing between two copies > of the TLV, to ensure that behavior is consistent across the domain. > > Another question this raises for an implementer is this - how does a > router know if TLV A and TLV B are two copies of the same TLV, rather > than being different TLVs? If the capabilities TLV were to include an > extra byte to identify a particular instance of the TLV, then I think > this would all become much simpler. (This identifier would also reduce > the amount of checking required in order to prevent the leaking of > multiple copies of the same TLV from level 2 into level 1.) two copies of the TLV, I think is talking about the CAP TLV, the same sub-TLVs appear in two different LSPs, e.g. a TE proxy server sub-TLV listed two different servers. there is no definite way of determine which one is the most recent one, and hopefully this is in a transient state, and it will converge. if you are talking about one particular sub-TLV has so much data which needs to use two seperate TLVs, then remember the "extended-TLV" draft? which was exactly triggered by this CAP TLV discussion. > > 4) The second paragraph of section 4 has the phrase "...at least one > L1/L2 Router in every area of the domain MUST support the Router > CAPABILITY TLV." I think this comes out a bit stronger than the > intended meaning! > > Would it be better to change the sentence to read as follows "In a > network where Router CAPABILITY TLVs with domain-wide scope originated > by L1 Routers are required to be flooded across the entire domain, then > it is necessary for at least one L1/L2 Router in every area of the > domain to support the Router CAPABILITY TLV." sounds fine with me. actually this "by L1 Routers" is not accurate, a CAP TLV can also be generated by a "L2 or L1/L2 Routers". thanks. - Naiming > > It may also be worth noting that this is an operational requirement, > rather than being something required for an implementation of the > protocol. > > Let me know what you think! > 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 Mar 9 10:36:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16523 for ; Wed, 9 Mar 2005 10:36:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Cw-0008Cm-LN; Wed, 09 Mar 2005 10:34:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Cu-0008Cf-9p for isis-wg@megatron.ietf.org; Wed, 09 Mar 2005 10:34:44 -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 KAA16356 for ; Wed, 9 Mar 2005 10:34:41 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93FV-0002Xy-Pt for isis-wg@ietf.org; Wed, 09 Mar 2005 10:37:27 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt Date: Wed, 9 Mar 2005 15:34:28 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7069BC843@duke.datcon.co.uk> Thread-Topic: [Isis-wg] Re: Comments on draft-ietf-isis-caps-00.txt Thread-Index: AcUkZSuNglklK8niTbSegfskJXsh3QATVBHg From: "Jonathan Harrison" To: "Naiming Shen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: jvasseur@cisco.com, isis-wg@ietf.org, rahul@juniper.net 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 Naiming, Les, Thanks for the explanations. Would it be possible to put some of this = information into the draft, to avoid these questions coming up again = (and again!)? 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 Mar 9 15:53:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19593 for ; Wed, 9 Mar 2005 15:53:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D989r-0004lZ-SM; Wed, 09 Mar 2005 15:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D989q-0004lU-HD for isis-wg@megatron.ietf.org; Wed, 09 Mar 2005 15:51:54 -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 PAA19446 for ; Wed, 9 Mar 2005 15:51:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98CU-0002TI-N3 for isis-wg@ietf.org; Wed, 09 Mar 2005 15:54:40 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 12:52:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208,217"; a="166208068:sNHT49083616" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29KpQYO007968; Wed, 9 Mar 2005 12:51:27 -0800 (PST) Received: from ginsberg-w2k01.cisco.com (spandya-w2k.cisco.com [128.107.163.50]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYX27083; Wed, 9 Mar 2005 12:51:26 -0800 (PST) Message-Id: <4.3.2.7.2.20050309123507.02339e30@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Mar 2005 12:51:26 -0800 To: "Jonathan Harrison" From: Les Ginsberg Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt In-Reply-To: <37701240971DD31193970000F6CCB9F7069BC843@duke.datcon.co.uk > Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: jvasseur@cisco.com, isis-wg@ietf.org, rahul@juniper.net 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="===============0076742426==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0076742426== Content-Type: multipart/alternative; boundary="=====================_6905539==_.ALT" --=====================_6905539==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:34 PM 3/9/2005 +0000, Jonathan Harrison wrote: >Naiming, Les, > >Thanks for the explanations. Would it be possible to put some of this >information into the draft, to avoid these questions coming up again (and >again!)? > >Thanks, >Jon Jon - There are a number of authors of this draft, so any changes would require some consensus. But, referring to your original points by number, I will summarize my view of what changes might be made. 1) The use of router ID We should explicitly state: "A router which generates a capability TLV MUST also generate a Traffic Engineering Router ID TLV (134) at each level for which it generates a router capability TLV." I don't think we need to explain why we DIDN'T use system ID. 2) "a system should not use capability TLVs unless the advertiser of the LSP containing the TLV is currently reachable..." Some explanatory text as to the motivation would be helpful. TBD 3) Multiple copies of a capabilities TLV... I prefer to leave the text as written. As I indicated in my earlier response, this is a generic problem not unique to the capabilities TLV. As such, if something needs to be said, it needs to be said in someplace that has a larger context. ("If" something needs to be said...) 4)Rewording of the second paragraph of section 4. I am OK with the text as written, but if we decide to accept your alternative we should correct it as pointed out by Naiming to not restrict the text to referring to capability TLVs generated only by L1 systems. The issue isn't with the original source of the TLV, but with the scope of the flooding of the information. Les --=====================_6905539==_.ALT Content-Type: text/html; charset="us-ascii" At 03:34 PM 3/9/2005 +0000, Jonathan Harrison wrote:
Naiming, Les,

Thanks for the explanations.  Would it be possible to put some of this information into the draft, to avoid these questions coming up again (and again!)?

Thanks,
Jon

Jon -

There are a number of authors of this draft, so any changes would require some consensus. But, referring to your original points by number,  I will summarize my view of what changes might be made.

1) The use of router ID

We should explicitly state:

"A router which generates a capability TLV MUST also generate a Traffic Engineering Router ID TLV (134) at each level for which it generates a router capability TLV."

I don't think we need to explain why we DIDN'T use system ID.

2) "a system should not use capability TLVs unless the advertiser of the LSP containing the TLV is currently reachable..."

Some explanatory text as to the motivation would be helpful. TBD

3) Multiple copies of a capabilities TLV...

I prefer to leave the text as written.
As I indicated in my earlier response, this is a generic problem not unique to the capabilities TLV. As such, if something needs to be said, it needs to be said in someplace that has a larger context. ("If" something needs to be said...)

4)Rewording of  the second paragraph of section 4.

I am OK with the text as written, but if we decide to accept your alternative we should correct it as pointed out by Naiming to not restrict the text to referring to capability TLVs generated only by L1 systems. The issue isn't with the original source of the TLV, but with the scope of the flooding of the information.

   Les
--=====================_6905539==_.ALT-- --===============0076742426== 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 --===============0076742426==-- From kdbzdu@doramail.com Thu Mar 10 00:38:42 2005 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 AAA05888; Thu, 10 Mar 2005 00:38:42 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9GQQ-0005Go-Jh; Thu, 10 Mar 2005 00:41:35 -0500 Received: from yahoobb221075140012.bbtec.net ([221.75.140.12]) by mx2.foretec.com with smtp (Exim 4.24) id 1D9GNc-00042T-H0; Thu, 10 Mar 2005 00:38:41 -0500 Received: from epidermis.dostmail.com ([198.175.228.75]) by heavy.wowmail.com (InterMail vK.4.04.00.03 354-564-996-20030725 license 832941yz85lu9dlf2tx127i8m14i5z84) with SMTP id <20040335326305.PNIK79597.heavy@epidermis.dostmail.com> for ; Thu, 10 Mar 2005 07:38:08 +0200 Date: Thu, 10 Mar 2005 07:38:08 +0200 From: Angelica Sewell Subject: Re: Real man looking for a real woman To: Message-ID: <752591867805.YEU57764@freehongkong.com> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_0916_75O60EI2.14ZS1109" X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Mar 2005 00:38:41 -0500 X-Spam-Score: 9.6 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------_001_0916_75O60EI2.14ZS1109 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit http://cadre.volosko.com/575r.html http://burt.volosko.com/nothanks.php autocratic emigrateboar capita halleypericlean grindstone innermostcholesterol lodgepole illiteracyconfucianism emission contemporarybasswood aloft depleterestrict etch regalcouncilwoman siegfried luxurybaton libel saxontritium ------_001_0916_75O60EI2.14ZS1109 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7Bit




N^V^R




carbide kneecaphabitation chug sumatrabenson archetypical cayleydialect discriminate barbudohabeas virtuous allemandadmire awhile americanaplatonist marlowe algorithmcontaminate expletive faucetable abate appraisalextralegal ------_001_0916_75O60EI2.14ZS1109-- From isis-wg-bounces@ietf.org Fri Mar 11 16:43:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10150 for ; Fri, 11 Mar 2005 16:43:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rt7-0002vb-9D; Fri, 11 Mar 2005 16:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rt4-0002vW-7N for isis-wg@megatron.ietf.org; Fri, 11 Mar 2005 16:41:38 -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 QAA10112 for ; Fri, 11 Mar 2005 16:41:36 -0500 (EST) From: amitsolanki@yahoo.com Received: from web30201.mail.mud.yahoo.com ([68.142.200.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9rw9-0003ip-21 for isis-wg@ietf.org; Fri, 11 Mar 2005 16:44:49 -0500 Received: (qmail 60120 invoked by uid 60001); 11 Mar 2005 21:41:28 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=zJooCU8cWc9asfvPj2l343KyH2XK+1/1MnD302jOBNfal/zeHPKCY9DXVYoUrce1/rIdx5Vv8exkhoKaL6M+Zw+14QhA1t4eC9cTd4mdlPIfGUvz/RpPlArbpxLMGYJcHByDavYqm6/gqpgJppOCgwxjXfknQcnuxVBQnA/3hE8= ; Message-ID: <20050311214128.60118.qmail@web30201.mail.mud.yahoo.com> Received: from [47.234.0.52] by web30201.mail.mud.yahoo.com via HTTP; Fri, 11 Mar 2005 13:41:28 PST Date: Fri, 11 Mar 2005 13:41:28 -0800 (PST) To: ISIS WG In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA10112 Subject: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.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: quoted-printable Here are my observations about the ISIS-draft-18 MIB. 1) I noticed that two table has index defined as OCTET STRING of SIZE (0..20).=20 isisManAreaAddrEntry OBJECT-TYPE SYNTAX IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address manually configured on this system" INDEX { isisManAreaAddr } ::=3D { isisManAreaAddrTable 1 } IsisManAreaAddrEntry ::=3D SEQUENCE { isisManAreaAddr =20 IsisOSINSAddress, isisManAreaAddrExistState RowStatus } isisAreaAddrEntry OBJECT-TYPE SYNTAX IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address reported in a Level 1 LSP generated or received by this Intermediate System." INDEX { isisAreaAddr } ::=3D { isisAreaAddrTable 1 } IsisAreaAddrEntry ::=3D SEQUENCE { isisAreaAddr IsisOSINSAddress } IsisOSINSAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "OSI Network Service Address, e.g. NSAP, SNPA, or Network Entity Title" SYNTAX OCTET STRING (SIZE(0..20)) A table with index of zero does not look correct to me. 2) I have noticed that most of tables do not follow the naming convention defined in section =93Appendix C:=20 Suggested Naming Conventions=94 of http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 04.txt - The descriptor associated with the MODULE-IDENTITY invocation should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx is a mixed-case version of XXX starting with a lower-case letter and without any hyphens. For example, the OPT-IF-MIB uses the prefix optIf, and the descriptor associated with its MODULE-IDENTITY invocation is optIfMibModule. I have to list whatever I could find in the MIB: a) isisManAreaAddr in isisManAreaAddrTable. Suggest name is isisManAreaAddrAddress b) isisAreaAddr in isisAreaAddrTable. Suggest name is isisAreaAddrAddress c) isisSummAddressType and isisSummAddress in isisSummAddrTable. Suggest names are isisSummAddrType and isisSummAddrAddress. d) Most of column in isisSystemCounterTable table do not follow the naming convention. e) Most of column in isisCircuitCounterTable table do not follow the naming convention. f) Most of column in isisPacketCounterTable table do not follow the naming convention. I not sure if these comments have been made by someone or not. Please excuse me if somebody else has already reported about this or if the above listed comments are not valid. Regards, Amit =09 __________________________________=20 Do you Yahoo!?=20 Yahoo! Mail - Helps protect you from nasty viruses.=20 http://promotions.yahoo.com/new_mail _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Mar 11 16:57:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11257 for ; Fri, 11 Mar 2005 16:57:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9s6w-0005w7-Gb; Fri, 11 Mar 2005 16:55:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9s6v-0005w2-PY for isis-wg@megatron.ietf.org; Fri, 11 Mar 2005 16:55:57 -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 QAA11134 for ; Fri, 11 Mar 2005 16:55:55 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9sA0-0004Py-V3 for isis-wg@ietf.org; Fri, 11 Mar 2005 16:59:09 -0500 Received: from dgoodspeedpc ([172.22.184.130] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Mar 2005 13:55:43 -0800 From: "Don Goodspeed" To: , "'ISIS WG'" Subject: RE: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt Date: Fri, 11 Mar 2005 13:55:57 -0800 Message-ID: <004701c52685$1b6ea8b0$f703a8c0@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20050311214128.60118.qmail@web30201.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-OriginalArrivalTime: 11 Mar 2005 21:55:43.0536 (UTC) FILETIME=[12A6E300:01C52685] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 8bit 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 8bit Amit, I'll let Jeff comment on issue #2. On issue #1, the TC is correct in it's size but we should add a range constraint on the table indices of SIZE(1..20). Thanks, Don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of amitsolanki@yahoo.com Sent: Friday, March 11, 2005 1:41 PM To: ISIS WG Subject: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt Here are my observations about the ISIS-draft-18 MIB. 1) I noticed that two table has index defined as OCTET STRING of SIZE (0..20). isisManAreaAddrEntry OBJECT-TYPE SYNTAX IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address manually configured on this system" INDEX { isisManAreaAddr } ::= { isisManAreaAddrTable 1 } IsisManAreaAddrEntry ::= SEQUENCE { isisManAreaAddr IsisOSINSAddress, isisManAreaAddrExistState RowStatus } isisAreaAddrEntry OBJECT-TYPE SYNTAX IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address reported in a Level 1 LSP generated or received by this Intermediate System." INDEX { isisAreaAddr } ::= { isisAreaAddrTable 1 } IsisAreaAddrEntry ::= SEQUENCE { isisAreaAddr IsisOSINSAddress } IsisOSINSAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "OSI Network Service Address, e.g. NSAP, SNPA, or Network Entity Title" SYNTAX OCTET STRING (SIZE(0..20)) A table with index of zero does not look correct to me. 2) I have noticed that most of tables do not follow the naming convention defined in section Appendix C: Suggested Naming Conventions of http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04. txt - The descriptor associated with the MODULE-IDENTITY invocation should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx is a mixed-case version of XXX starting with a lower-case letter and without any hyphens. For example, the OPT-IF-MIB uses the prefix optIf, and the descriptor associated with its MODULE-IDENTITY invocation is optIfMibModule. I have to list whatever I could find in the MIB: a) isisManAreaAddr in isisManAreaAddrTable. Suggest name is isisManAreaAddrAddress b) isisAreaAddr in isisAreaAddrTable. Suggest name is isisAreaAddrAddress c) isisSummAddressType and isisSummAddress in isisSummAddrTable. Suggest names are isisSummAddrType and isisSummAddrAddress. d) Most of column in isisSystemCounterTable table do not follow the naming convention. e) Most of column in isisCircuitCounterTable table do not follow the naming convention. f) Most of column in isisPacketCounterTable table do not follow the naming convention. I not sure if these comments have been made by someone or not. Please excuse me if somebody else has already reported about this or if the above listed comments are not valid. Regards, Amit __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ 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 Sat Mar 12 02:47:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14478 for ; Sat, 12 Mar 2005 02:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA1Iw-0005ly-V3; Sat, 12 Mar 2005 02:44:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA1Is-0005kX-9g for isis-wg@megatron.ietf.org; Sat, 12 Mar 2005 02:44:54 -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 CAA14226 for ; Sat, 12 Mar 2005 02:44:50 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA1Lz-00055x-I3 for isis-wg@ietf.org; Sat, 12 Mar 2005 02:48:08 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j2C7ie9s030488 for ; Fri, 11 Mar 2005 23:44:40 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2C7imq6014607 for ; Fri, 11 Mar 2005 23:44:48 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2C7ilQr014604 for ; Fri, 11 Mar 2005 23:44:47 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 11 Mar 2005 23:44:47 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG Subject: Re: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt In-Reply-To: <20050311214128.60118.qmail@web30201.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 On Fri, 11 Mar 2005 amitsolanki@yahoo.com wrote: > Here are my observations about the ISIS-draft-18 MIB. > > 1) I noticed that two table has index defined as OCTET > STRING of SIZE (0..20). ... > A table with index of zero does not look correct to me. Actually, there is nothing wrong with this. These are variable length strings without the IMPLIED keyword, so the length will be included as a sub-identifier in the instance identification part of a column's OID. //cmh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Mar 12 15:37:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06033 for ; Sat, 12 Mar 2005 15:37:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADHb-0005Oj-S9; Sat, 12 Mar 2005 15:32:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADHZ-0005Od-Nf for isis-wg@megatron.ietf.org; Sat, 12 Mar 2005 15:32:21 -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 PAA05490 for ; Sat, 12 Mar 2005 15:32:19 -0500 (EST) From: amitsolanki@yahoo.com Received: from web30205.mail.mud.yahoo.com ([68.142.200.88]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DADKr-0006ni-1L for isis-wg@ietf.org; Sat, 12 Mar 2005 15:35:45 -0500 Received: (qmail 22536 invoked by uid 60001); 12 Mar 2005 20:32:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=B6FHVJtVyQ2zbmvOJwAE2fydKtIiLoWjbCoDLYrIX5/kOP6KUx+ceOhYSDMRS7fR0g+yshEjTb9ngNyf6aQUGJ/3tjAA0iHTS7KQyCSvt2Qqt64unYyW/qprrf45znBmBqWJez43a4PqPQT4Dkz7DTuirEfWFviFmZbyvCgxwOk= ; Message-ID: <20050312203212.22534.qmail@web30205.mail.mud.yahoo.com> Received: from [66.30.17.80] by web30205.mail.mud.yahoo.com via HTTP; Sat, 12 Mar 2005 12:32:12 PST Date: Sat, 12 Mar 2005 12:32:12 -0800 (PST) Subject: Re: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt To: "C. M. Heard" , ISIS WG In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.8 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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, I agree to whatever you are saying, but the variable I am talking about is an Index in one table and there is only one Index for the table. Please see below for the table. I think that if we have a OCTET STRING as a only INDEX then the minimun STRING length should be 2 (If IMPLIED keyword is not used). First OCTET to represent the length and second is the value, as you mentioned. Then if I think again it seems that in this table there is only one OCTET STRING Index and that too read-only so we should add IMPLIED keyword. Please correct me if this does not make sense. The table ... isisAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The union of the sets of area addresses reported in all Level 1 LSPs with fragment number zero generated by this Intermediate System, or received from other Intermediate Systems which are reachable via Level 1 routing." REFERENCE "{ISIS.aoi areaAddresses (18)}" ::= { isisSystem 3 } IsisAreaAddrEntry ::= SEQUENCE { isisAreaAddr IsisOSINSAddress } isisAreaAddr OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An area address reported in a Level 1 LSP." Regards, Amit --- "C. M. Heard" wrote: > On Fri, 11 Mar 2005 amitsolanki@yahoo.com wrote: > > Here are my observations about the ISIS-draft-18 > MIB. > > > > 1) I noticed that two table has index defined as > OCTET > > STRING of SIZE (0..20). > ... > > A table with index of zero does not look correct > to me. > > Actually, there is nothing wrong with this. These > are variable > length strings without the IMPLIED keyword, so the > length will be > included as a sub-identifier in the instance > identification part of > a column's OID. > > //cmh > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 13 13:38:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01111 for ; Sun, 13 Mar 2005 13:38: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 1DAXxO-0007bz-G8; Sun, 13 Mar 2005 13:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAXxN-0007bu-A0 for isis-wg@megatron.ietf.org; Sun, 13 Mar 2005 13:36:53 -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 NAA01050 for ; Sun, 13 Mar 2005 13:36:49 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAY0p-0002Mg-0p for isis-wg@ietf.org; Sun, 13 Mar 2005 13:40:28 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j2DIad9s021964; Sun, 13 Mar 2005 10:36:39 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2DIakFA030999; Sun, 13 Mar 2005 10:36:46 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2DIakok030995; Sun, 13 Mar 2005 10:36:46 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 13 Mar 2005 10:36:46 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: amitsolanki@yahoo.com Subject: Re: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt In-Reply-To: <20050312203212.22534.qmail@web30205.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ISIS WG 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 On Sat, 12 Mar 2005 amitsolanki@yahoo.com wrote: > I agree to whatever you are saying, but the variable I > am talking about is an Index in one table and there is > only one Index for the table. Please see below for the > table. [ the table in question is isisAreaAddrTable, whose only ] [ index is the object isisAreaAddr. That object is also ] [ the only column in the table and to its MAX-ACCESS is ] [ read-only. Its type is IsisOSINSAddress, which resolves ] [ to OCTET STRING (SIZE(0..20)). ] > I think that if we have a OCTET STRING as a only INDEX > then the minimun STRING length should be 2 (If IMPLIED > keyword is not used). > First OCTET to represent the length and second is the > value, as you mentioned. Why do you think that? It is not a requirement of the SMI, as far as I can tell from reading RFC 2578, and there is no reason why a zero-length instance of isisAreaAddr could not be successfully retrieved with an SNMP get request. Whether there is any real-world situation where the it makes sense for the object isisAreaAddr to have zero length is a separate question. > Then if I think again it seems that in this table > there is only one OCTET STRING Index and that too > read-only so we should add IMPLIED keyword. IMPLIED is generally NOT RECOMMENDED anymore ... see draft-ietf-ops-mib-review-guidelines-04.txt section 4.6.4. Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 13 18:05:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18874 for ; Sun, 13 Mar 2005 18:05:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAc5s-0006f5-FV; Sun, 13 Mar 2005 18:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAc5q-0006f0-Me for isis-wg@megatron.ietf.org; Sun, 13 Mar 2005 18:01:54 -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 SAA18546 for ; Sun, 13 Mar 2005 18:01:52 -0500 (EST) From: amitsolanki@yahoo.com Received: from web30208.mail.mud.yahoo.com ([68.142.200.91]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DAc9J-0002sq-V7 for isis-wg@ietf.org; Sun, 13 Mar 2005 18:05:32 -0500 Received: (qmail 64168 invoked by uid 60001); 13 Mar 2005 23:01:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=OjtrmQ+E57N46tSxeSkFxiBCY2BhEBeMEWN9CVXieMPxXK/E/sHX2xHKww7boTkbD1CdGeW6sU9yGbV64fGEq6yicIxC7AjV53TS2raJE/RiK16juFnUh+Z7mZG+z+VTY+Hz/7PgTIPw9dha+OHaWaPY6pNA4xAMJt4KFQ6qWhE= ; Message-ID: <20050313230142.64166.qmail@web30208.mail.mud.yahoo.com> Received: from [66.30.17.80] by web30208.mail.mud.yahoo.com via HTTP; Sun, 13 Mar 2005 15:01:42 PST Date: Sun, 13 Mar 2005 15:01:42 -0800 (PST) Subject: Re: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt To: "C. M. Heard" In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ISIS WG 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 [ Whether there is any real-world situation where the it [ makes sense for the object isisAreaAddr to have zero [ length is a separate question. ] You are right in case of Index being zero, I am talking from implementation point of view because if we go by MIB definition it seems that no value is also a valid value. In case of isisAreaAddrTable it is still ok as this is read-only. But in isisManAreaAddrTable we have read-create situation with INDEX of type IsisOSINSAddress. In case of isisManAreaAddrTable then a no index value will also be a valid value and an entry should be created. Expert opinion is required here, I am not able to figure out how to implement this. Thanks for pointing out about the IMPLIED keyword. I realised it later, it was an error from my side in saying that as we cannot do that, because if we do that managers will not know what is the length of the Area Address. I have one more question related to the isisAreaAddrTable, in this table we have INDEX as isisAreaAddr whose MAX-ACCESS is read-only. Since this is an INDEX in the table shouldn't the MAX-ACCESS be not-accessible based on SMIv2. I understand that if we make this not-accessible then the MIB compilation may fail as some compilars assume that there should be atleast on not-accessible paramters in the Table. Pardon my ignorance here, could you help me in understanding this. Regards, Amit --- "C. M. Heard" wrote: > On Sat, 12 Mar 2005 amitsolanki@yahoo.com wrote: > > I agree to whatever you are saying, but the > variable I > > am talking about is an Index in one table and > there is > > only one Index for the table. Please see below for > the > > table. > > [ the table in question is isisAreaAddrTable, whose > only ] > [ index is the object isisAreaAddr. That object is > also ] > [ the only column in the table and to its MAX-ACCESS > is ] > [ read-only. Its type is IsisOSINSAddress, which > resolves ] > [ to OCTET STRING (SIZE(0..20)). > ] > > > I think that if we have a OCTET STRING as a only > INDEX > > then the minimun STRING length should be 2 (If > IMPLIED > > keyword is not used). > > First OCTET to represent the length and second is > the > > value, as you mentioned. > > Why do you think that? It is not a requirement of > the > SMI, as far as I can tell from reading RFC 2578, and > there is no reason why a zero-length instance of > isisAreaAddr could not be successfully retrieved > with > an SNMP get request. > > Whether there is any real-world situation where the > it > makes sense for the object isisAreaAddr to have zero > length is a separate question. > > > Then if I think again it seems that in this table > > there is only one OCTET STRING Index and that too > > read-only so we should add IMPLIED keyword. > > IMPLIED is generally NOT RECOMMENDED anymore ... see > > draft-ietf-ops-mib-review-guidelines-04.txt section > 4.6.4. > > Mike Heard > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 13 20:34:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29318 for ; Sun, 13 Mar 2005 20:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeQ9-0003k4-EE; Sun, 13 Mar 2005 20:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeQ8-0003jz-Eu for isis-wg@megatron.ietf.org; Sun, 13 Mar 2005 20:31:00 -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 UAA28925 for ; Sun, 13 Mar 2005 20:30:57 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAeTe-0007Zq-N1 for isis-wg@ietf.org; Sun, 13 Mar 2005 20:34:39 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j2E1Ud9s000789; Sun, 13 Mar 2005 17:30:40 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2E1UlfI013394; Sun, 13 Mar 2005 17:30:47 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2E1UlqV013391; Sun, 13 Mar 2005 17:30:47 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 13 Mar 2005 17:30:47 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: amitsolanki@yahoo.com Subject: Re: [Isis-wg] Review of: draft-ietf-isis-wg-mib-18.txt In-Reply-To: <20050313230142.64166.qmail@web30208.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ISIS WG 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 On Sun, 13 Mar 2005 amitsolanki@yahoo.com wrote: > [ Whether there is any real-world situation where it > [ makes sense for the object isisAreaAddr to have zero > [ length is a separate question. ] > > You are right in case of Index being zero, I am > talking from implementation point of view because if > we go by MIB definition it seems that no value is also > a valid value. > > In case of isisAreaAddrTable it is still ok as this is > read-only. But in isisManAreaAddrTable we have > read-create situation with INDEX of type > IsisOSINSAddress. In case of isisManAreaAddrTable then > a no index value will also be a valid value and an > entry should be created. > > Expert opinion is required here, I am not able to > figure out how to implement this. OK. The only INDEX object in isisAreaAddrEntry is the the columnar object isisManAreaAddr, which as you say has a MAX-ACCESS value of not-accessible. So to create a row a manager has to specify an pair for the status column isisManAreaAddrExistState. In particular, if it is desired for some reason to create a row where the value of isisManAreaAddr is a zero-length OCTET STRING, then the manager would issue a set request varbind whose name field is { isisManAreaAddrExistState 0 } and whose value field is createAndGo(4) (createAndWait(5) would also be legal, although there is not much point to that). The agent should then create the specified instance of isisManAreaAddrExistState if it can do so. If this is still not clear I suggest that we take the discussion off-line. //cmh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Mar 15 12:42:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27420 for ; Tue, 15 Mar 2005 12:42:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFx1-0008Cd-2q; Tue, 15 Mar 2005 12:35:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFwz-0008Bq-44 for isis-wg@megatron.ietf.org; Tue, 15 Mar 2005 12:35:25 -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 MAA26747 for ; Tue, 15 Mar 2005 12:35:17 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFmC-0003ty-8K for isis-wg@ietf.org; Tue, 15 Mar 2005 12:24:18 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id CDADCE00032A for ; Tue, 15 Mar 2005 17:20:03 +0000 (GMT) Received: from Puppy ([212.43.203.66] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 17:20:03 +0000 Message-ID: <01bb01c52983$73e10af0$dccb2bd4@Puppy> From: "Adrian Farrel" To: "ISIS-WG (E-mail)" References: <775daa9818278993bbb46ba31a9a1fea@rawdofmt.org> Subject: Re: [Isis-wg] WG Last Call: draft-ietf-isis-caps-00.txt Date: Tue, 15 Mar 2005 10:44:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 15 Mar 2005 17:20:04.0297 (UTC) FILETIME=[3A264B90:01C52983] X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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 Hi, There's some boilerplate nonsense to be sorted out, and a host of non-ASCII characters. Section 2. Note that your text is not consistent with your table. The text says that you should have... TYPE: 242 (To be assigned by IANA) LENGTH: from 5 to 255 FLAGS (1 octet) VALUE: Router ID (4 octets) Set of optional sub-TLVs (0-250 octets) But this is clearly not what the table says. Section 2. Although we should all know how ISIS TLVs are formed, it appears that you cannot go wrong by being incredibly clear about the meaning of the value contained in the Length field. You say that it specifies the TLV length, but you also say that it has a minimum value of 5 which suggests it is actually the length of the V *and* that the Flags are part of the V. Section 5. Seems like this draft is proposing a mechanism for advertising the capabilities of routers more widely. Since there is plenty of scope for people to snoop on ISIS advertiesements (from way across the network) this mechanism necessarily makes available to any listener more information about routers than was previously available. This is a change in the security, I think. Section 8. It is usual to give section numbers to the subsections in the references section. Cheers, Adrian _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Mar 15 15:17:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11763 for ; Tue, 15 Mar 2005 15:00:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHx7-00073J-Ul; Tue, 15 Mar 2005 14:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHx5-000717-8i for isis-wg@megatron.ietf.org; Tue, 15 Mar 2005 14:43:40 -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 OAA09782 for ; Tue, 15 Mar 2005 14:43:36 -0500 (EST) From: jcucchiara@mindspring.com Received: from granger.mail.mindspring.net ([207.69.200.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHzs-00019b-Qd for isis-wg@ietf.org; Tue, 15 Mar 2005 14:46:33 -0500 Received: from h-66-167-248-207.cmbrmaor.dynamic.covad.net ([66.167.248.207] helo=jluciani-laptop) by granger.mail.mindspring.net with smtp (Exim 3.33 #1) id 1DBHvk-0001LP-00; Tue, 15 Mar 2005 14:42:16 -0500 Message-Id: <3.0.1.32.20050315022834.0133f988@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 15 Mar 2005 02:28:34 -0500 To: "C. M. Heard" , Jeff Parker Subject: Re: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-18.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder , ISIS WG 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 Mike, Thanks for a great review. There is one object which I would like to see added. This was discussed in emails to the list in August 2004 timeframe and there seemed to be some favor in adding it, but I don't see this in the current rev of the MIB. The object is: isisCircOperState OBJECT-TYPE SYNTAX INTEGER { operStatusUp(1), -- active operStatusDown(2), -- inactive operStatusGoingUp(3), -- activating operStatusGoingDown(4),-- deactivating operStatusActFailed(5) -- activation failed } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of this circuit." ::= { isisCircEntry 5 } The text in the isisSysType and isisCircLevel descriptions need to be clarified. Also, shouldn't there be some errors returned under certain circumstances? For example, if the sysType object is Level1, then an operator should receive an error if the circLevel is set to Level2 or Level1Level2 (would guess an Inconsistent Value error would be appropriate). Additional text for the isisCircLevelTable is also needed for example: - Two entries in the isisCircLevelTable exist for every isisCircTable entry. One for level 1 and one for level 2. For example: "This table will contain 2 rows (one for level1 and one for level2) per circuit. Both of the rows per circuit will be "in use" if the SysType and CircuitType corresponding to this row is Level1Level2. If the value of SysType is Level1 or Level1Level2 and the value of CircuitType is Level1, then only the level1 row will be in use and the level2 row is not in use. If the value of SysType is Level1Level2 or Level2 and the value of CircuitType is Level2, then only the level2 row will be in use and the level1 row is not in use." thanks, Joan At 05:47 PM 3/6/05 -0800, C. M. Heard wrote: >Jeff - > >I suspected that the question I raised in 10(m) below might just be >a result of my limited understanding of IS-IS. If the WG is happy >with the object definition as it stands, then so am I. > >Regards, > >Heard > >On Sun, 6 Mar 2005, Parker, Jeff wrote: >> Mike - >> I accept (almost) all of your comments, and I'm you didn't >> get to (z) in your list of points. One comment on (m). >> >> IS-IS does not depend on IP, and it does it's own >> fragmentation at the packet source. Think "PDU" when you read >> "Fragment". >> I could use the 10589 term, "LSP number field", rather than >> "Fragment Number", but that term seems more ambiguous to me, as >> the LSP is full of numbers. >> >> This fragmentation scheme leads to a great deal of confusion >> when routers have a different value for the MTU, which gave rise >> to a number of Notifications about OriginatingBufferSize and the >> like. >> >> - jeff >> >> > (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: >> > "The 8 byte LSP ID, consisting of the SystemID, >> > Circuit ID, and Fragment Number." >> > Maybe this is a stupid question, but shouldn't the >> > isisLSPSummaryTable be concerning itself with entire reassembled >> > link state PDUs and not individual fragments thereof? If so, >> > perhaps the DESCRIPTION clause should be revised. (If this were >> > IPv4, and I were describing a complete, reassembled IP PDU, I >> > would specify that Fragment Offset=0 and MF=0, and I would also >> > stipulate that the checksum is what would have been computed for >> > the complete datagram prior to fragmentation. But perhaps those >> > considerations don't apply here.) >> >> > > >_______________________________________________ >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 Mar 15 16:45:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24331 for ; Tue, 15 Mar 2005 16:45:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJoZ-0007qq-Gg; Tue, 15 Mar 2005 16:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJoW-0007oY-F0 for isis-wg@megatron.ietf.org; Tue, 15 Mar 2005 16:42:56 -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 QAA24156 for ; Tue, 15 Mar 2005 16:42:54 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJsQ-0002GE-Lk for isis-wg@ietf.org; Tue, 15 Mar 2005 16:46:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Mar 2005 13:43:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2FLfwuC001968; Tue, 15 Mar 2005 13:41:59 -0800 (PST) Received: from ginsberg-w2k01.cisco.com (spandya-w2k.cisco.com [128.107.163.50]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZB86063; Tue, 15 Mar 2005 13:42:00 -0800 (PST) Message-Id: <4.3.2.7.2.20050315133841.022cde68@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Mar 2005 13:42:00 -0800 To: Adrian Farrel From: Les Ginsberg Subject: Re: [Isis-wg] WG Last Call: draft-ietf-isis-caps-00.txt In-Reply-To: <01bb01c52983$73e10af0$dccb2bd4@Puppy> References: <775daa9818278993bbb46ba31a9a1fea@rawdofmt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 At 10:44 AM 3/15/2005 +0000, Adrian Farrel wrote: >Hi, > >There's some boilerplate nonsense to be sorted out, and a host of >non-ASCII characters. > >Section 2. Note that your text is not consistent with your table. The text >says that you should have... > TYPE: 242 (To be assigned by IANA) > LENGTH: from 5 to 255 > FLAGS (1 octet) > VALUE: > Router ID (4 octets) > Set of optional sub-TLVs (0-250 octets) >But this is clearly not what the table says. > >Section 2. Although we should all know how ISIS TLVs are formed, it >appears that you cannot go wrong by being incredibly clear about the >meaning of the value contained in the Length field. You say that it >specifies the TLV length, but you also say that it has a minimum value of >5 which suggests it is actually the length of the V *and* that the Flags >are part of the V. Adrian - Seems like all of your concerns would be addressed by simply removing the phrase "1 octet of bit flags" from the first sentence of the first paragraph, which would then read: "The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet specifying the TLV length, and a variable length value field, starting with 4 octets of Router ID, indicating the source of the TLV, and followed by 1 octet of flags. A set of optional sub-TLVs may follow the flag field. ?? Les >Section 5. Seems like this draft is proposing a mechanism for advertising >the capabilities of routers more widely. Since there is plenty of scope >for people to snoop on ISIS advertiesements (from way across the network) >this mechanism necessarily makes available to any listener more >information about routers than was previously available. This is a change >in the security, I think. > >Section 8. It is usual to give section numbers to the subsections in the >references section. > >Cheers, >Adrian > > >_______________________________________________ >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 florence_k221@yahoo.co.uk Wed Mar 16 12:48:38 2005 Received: from mrson2839.com ([196.200.93.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14930 for ; Wed, 16 Mar 2005 12:48:36 -0500 (EST) Message-Id: <200503161748.MAA14930@ietf.org> Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.7.3]); Wed, 16 Mar 2005 17:46:23 +0100 From: "FLORENCE KEBE" Reply-To: florence_k222@yahoo.co.uk To: isis-archive@ietf.org Date: Wed, 16 Mar 2005 17:46:23 +0100 Subject: FROM FLORENCE KEBE X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello there=2C I am writting this letter with due respect and heartful of tears since we have not known or met ourselves previously I am asking for your assistance after I have gone through a profile that speaks good of you=2E I am sorry about the miss-up in registration=2EI want to find out if it's possible for you to deal with individual as to investment=2E I came across your profile and I feel it's highly reputable that is why I pick an interest getting across to you in respect of investment at my disposal=2E I will be so glad if you can allow me and lead me to the right channel towards your assistance to my situation now=2EI will make my proposal well known if Iam given the opportunity=2E I would like to use this opportunity to introduce myself to you=2E Well I am =28FLORENCE KEBE=2C=29 the only daughter of Mr=2E Mbokah Kebe=2C a diamond dealer from KENEMA in Sierra Leone=2E My father is now late=2Che died some months back during the last and current crisis in my country=28Sierra Leone=29=2E He was Killed by the rebels for refusing to join and sponsor them=2E The main reason why I am contacting you now is to seek your assistance in the area of my future investment and also for a help hand over some huge amount of money in my possession=2E This money =28US$10=2E2 Million=29 is deposited in a secuirty and finance company in London United Kingdom some years ago by my father and he made me the sole beneficiary=2E I am now asking you to stand on my behalf to claim the deposit from the security Finance company and assist me on investing it as well in your country=2E I have made up my mind to offer you 25%of the total money and also map out 5%for any expensive that will be made during the transaction while the remaining will go into a productive investment=2EAs I have mention earlier I will make the procedure to this issue to be well know to you=2Cif I am given the opportunity to do so=2E Pls attach your direct and full information as you reply to me with this email=2Eflorence=5Fk222=40yahoo=2Eco=2Euk Thanks and remain bless FLORENCE KEBE -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 From isis-wg-bounces@ietf.org Wed Mar 16 13:43:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20970 for ; Wed, 16 Mar 2005 13:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBdTd-0005vI-SM; Wed, 16 Mar 2005 13:42:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBdTb-0005v3-BL for isis-wg@megatron.ietf.org; Wed, 16 Mar 2005 13:42:39 -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 NAA20857 for ; Wed, 16 Mar 2005 13:42:35 -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 1DBdXg-0005lX-3e for isis-wg@ietf.org; Wed, 16 Mar 2005 13:46:52 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id ED3B53DCCAD; Wed, 16 Mar 2005 10:42:27 -0800 (PST) In-Reply-To: <3.0.1.32.20050315022834.0133f988@pop.mindspring.com> References: <3.0.1.32.20050315022834.0133f988@pop.mindspring.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <564b075349706431ebddb4c62d1802d4@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-18.txt Date: Wed, 16 Mar 2005 10:42:27 -0800 To: jcucchiara@mindspring.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder , ISIS WG , 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: 7bit While we haven't mentioned this on the list. We are locking down changes on the MIB. As soon as the MIB doctor review is done (and any required modification made) we will be doing a WG last call on the MIB. During this last call we will only allow changes to fix obvious problems with the MIB. If another LC is required we will only allow changes to the previous changes, and so forth until we have completed last call. IS-IS has been without a MIB for too long and there has been plenty of time to get this right. At some point we have to stop and get a standard MIB published. Now is that point. Thanks, Chris and Dave. On Mar 14, 2005, at 11:28 PM, jcucchiara@mindspring.com wrote: > > > Mike, > > Thanks for a great review. > > There is one object which I would like to see added. > This was discussed in emails to the list in August 2004 > timeframe and there seemed to be some favor in adding it, > but I don't see this in the current rev of the MIB. > > The object is: > > isisCircOperState OBJECT-TYPE > SYNTAX INTEGER { > operStatusUp(1), -- active > operStatusDown(2), -- inactive > operStatusGoingUp(3), -- activating > operStatusGoingDown(4),-- deactivating > operStatusActFailed(5) -- activation failed > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The operational state of this circuit." > ::= { isisCircEntry 5 } > > > > The text in the isisSysType and isisCircLevel descriptions need to be > clarified. > Also, shouldn't there be some errors returned under > certain circumstances? For example, if the sysType object is Level1, > then > an operator should receive an error if the circLevel is set to Level2 > or > Level1Level2 > (would guess an Inconsistent Value error would be appropriate). > > Additional text for the isisCircLevelTable is also needed for example: > > - Two entries in the isisCircLevelTable exist for every isisCircTable > entry. One for level 1 and one for level 2. For example: > > "This table will contain 2 rows (one for level1 and one for level2) per > circuit. Both of the rows per circuit will be "in use" if the SysType > and > CircuitType corresponding to this row is Level1Level2. If the > value of SysType is Level1 or Level1Level2 and the value of > CircuitType is > Level1, then > only the level1 row will be in use and the level2 row is not in use. > If the value of SysType is Level1Level2 or Level2 and the value of > CircuitType is Level2, then only the level2 row will be in use and the > level1 row is not in use." > > > thanks, Joan > > > At 05:47 PM 3/6/05 -0800, C. M. Heard wrote: >> Jeff - >> >> I suspected that the question I raised in 10(m) below might just be >> a result of my limited understanding of IS-IS. If the WG is happy >> with the object definition as it stands, then so am I. >> >> Regards, >> >> Heard >> >> On Sun, 6 Mar 2005, Parker, Jeff wrote: >>> Mike - >>> I accept (almost) all of your comments, and I'm you didn't >>> get to (z) in your list of points. One comment on (m). >>> >>> IS-IS does not depend on IP, and it does it's own >>> fragmentation at the packet source. Think "PDU" when you read >>> "Fragment". >>> I could use the 10589 term, "LSP number field", rather than >>> "Fragment Number", but that term seems more ambiguous to me, as >>> the LSP is full of numbers. >>> >>> This fragmentation scheme leads to a great deal of confusion >>> when routers have a different value for the MTU, which gave rise >>> to a number of Notifications about OriginatingBufferSize and the >>> like. >>> >>> - jeff >>> >>>> (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: >>>> "The 8 byte LSP ID, consisting of the SystemID, >>>> Circuit ID, and Fragment Number." >>>> Maybe this is a stupid question, but shouldn't the >>>> isisLSPSummaryTable be concerning itself with entire reassembled >>>> link state PDUs and not individual fragments thereof? If so, >>>> perhaps the DESCRIPTION clause should be revised. (If this were >>>> IPv4, and I were describing a complete, reassembled IP PDU, I >>>> would specify that Fragment Offset=0 and MF=0, and I would also >>>> stipulate that the checksum is what would have been computed for >>>> the complete datagram prior to fragmentation. But perhaps those >>>> considerations don't apply here.) >>> >>> >> >> >> _______________________________________________ >> 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-bounces@ietf.org Fri Mar 18 15:24:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21735 for ; Fri, 18 Mar 2005 15:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCO0K-00069l-Mt; Fri, 18 Mar 2005 15:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCO0H-00069a-MY for isis-wg@megatron.ietf.org; Fri, 18 Mar 2005 15:23:29 -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 PAA21500 for ; Fri, 18 Mar 2005 15:23:27 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO4l-0005ek-Cc for isis-wg@ietf.org; Fri, 18 Mar 2005 15:28:09 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 5514FE000191; Fri, 18 Mar 2005 20:23:17 +0000 (GMT) Received: from Puppy ([212.43.203.118] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 20:19:40 +0000 Message-ID: <064c01c52bf8$0b485260$dccb2bd4@Puppy> From: "Adrian Farrel" To: "Les Ginsberg" References: <775daa9818278993bbb46ba31a9a1fea@rawdofmt.org> <4.3.2.7.2.20050315133841.022cde68@mira-sjc5-3.cisco.com> Subject: Re: [Isis-wg] WG Last Call: draft-ietf-isis-caps-00.txt Date: Fri, 18 Mar 2005 18:38:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 20:19:41.0736 (UTC) FILETIME=[D13E3A80:01C52BF7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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 Les, Yes, I think the intention is that the flags are part of the V. Then the L covers the whole of the V including the flags. If this is the intention and all the text is made consistent, I'll be happy. I think slightly more work is needed to achieve consistency than you suggest, but that's just editorial noise. A ----- Original Message ----- From: "Les Ginsberg" To: "Adrian Farrel" Cc: "ISIS-WG (E-mail)" Sent: Tuesday, March 15, 2005 9:42 PM Subject: Re: [Isis-wg] WG Last Call: draft-ietf-isis-caps-00.txt > At 10:44 AM 3/15/2005 +0000, Adrian Farrel wrote: > >Hi, > > > >There's some boilerplate nonsense to be sorted out, and a host of > >non-ASCII characters. > > > >Section 2. Note that your text is not consistent with your table. The text > >says that you should have... > > TYPE: 242 (To be assigned by IANA) > > LENGTH: from 5 to 255 > > FLAGS (1 octet) > > VALUE: > > Router ID (4 octets) > > Set of optional sub-TLVs (0-250 octets) > >But this is clearly not what the table says. > > > >Section 2. Although we should all know how ISIS TLVs are formed, it > >appears that you cannot go wrong by being incredibly clear about the > >meaning of the value contained in the Length field. You say that it > >specifies the TLV length, but you also say that it has a minimum value of > >5 which suggests it is actually the length of the V *and* that the Flags > >are part of the V. > > Adrian - > > Seems like all of your concerns would be addressed by simply removing the > phrase "1 octet of bit flags" from the first sentence of the first > paragraph, which would then read: > > "The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, > 1 octet specifying the TLV length, and a > variable length value field, starting with 4 octets of Router ID, > indicating the source of the TLV, and followed by 1 octet of flags. A > set of optional sub-TLVs may follow the flag field. > > ?? > > Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Mar 18 16:05:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02863 for ; Fri, 18 Mar 2005 16:05:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOEE-0001rO-VB; Fri, 18 Mar 2005 15:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOEB-0001qm-MQ; Fri, 18 Mar 2005 15:37:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24248; Fri, 18 Mar 2005 15:37:49 -0500 (EST) Message-Id: <200503182037.PAA24248@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 18 Mar 2005 15:37:48 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-08.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 --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 : M-ISIS: Multi Topology (MT)Routing in IS-IS Author(s) : T. Przygienda, et al. Filename : draft-ietf-isis-wg-multi-topology-08.txt Pages : 12 Date : 2005-3-18 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-wg-multi-topology-08.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-wg-multi-topology-08.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: <2005-3-18153905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-18153905.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From nbqmrfm@nparsons.netlineuk.net Sat Mar 19 23:36:25 2005 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 XAA22065; Sat, 19 Mar 2005 23:36:24 -0500 (EST) Received: from wbar11.tampa1-4-4-132-128.tampa1.dsl-verizon.net ([4.4.132.128]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCsFe-0004UW-Mz; Sat, 19 Mar 2005 23:41:24 -0500 Received: from smelt.compuall.com ([12.183.179.18]) by doll.ewa.net (Sun Java System Messaging Server 6.1 HotFix 0.01 (built Aug 21 2004)) with SMTP id <0ICD00HGMY1D01Q0@doll.ewa.net> for serv@ietf.org (ORCPT serv@ietf.org); Sun, 20 Mar 2005 05:29:40 +0100 (IST) Received: (qmail 96107 invoked from network); Sat, 19 Mar 2005 23:28:40 -0500 Received: from unknown (HELO attorney.english.co.jp) (195.161.118.50) by server-9.bugging-75.compuall.com with SMTP; Sun, 20 Mar 2005 00:32:40 -0400 Received: by attorney with Internet Mail Service (5.5.3247.76) id ; Sun, 20 Mar 2005 07:28:40 +0300 Date: Sat, 19 Mar 2005 21:23:40 -0700 From: "Estella Lewis" To: Subject: New 0ffce sOftware s@|e Sender: "Estella Lewis" Message-ID: <103409535755.KSJ87225@attorney.ewa.net> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Java.PLPIJ.878982529273788579" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <937247@ATTYRRFY> X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 8.3 (++++++++) X-Spam-Flag: YES X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 This is a multi-part message in MIME format. --Java.PLPIJ.878982529273788579 Content-Type: multipart/alternative; boundary="Java.EAZIO.56985454784408013" --Java.EAZIO.56985454784408013 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit St0cks are runn|ng 0ut! --Java.EAZIO.56985454784408013 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
 
 
 
Get 1t whIle !t |asts
 
bricklaying checkerberry = shag affectionate lossy radiochemistry daimler binomial inertial deletion = digitate spectroscopic squire wail cotyledon cerulean pearson dickson opin= e bashful consecutive witty damascus beginner conference flocculate idioma= tic connubial calliope bijection certify chicano indecent radix scorch rad= ish
 
cobweb horseback similitu= de haberman metabolic dahomey isomer barrow bunk needle brookline vessel o= f reversible thyrotoxic spade teal inclusion isomorphic protestant whomsoe= ver allude abreast
 
alfresco dreamt glorious = basophilic arden johnsen impasse flatware laissez parr defraud dis godfrey= %RND hibbard
 
men col candle chamber fe= rromagnetic lawgiving televise pawnshop guildhall conestoga diva ass gent = diacritical upriver abelson humility as shag synthetic
 
concise osteopathy congre= gate reducible convergent thereupon those salesgirl triumph howell drophea= d idempotent offertory adjectival complicity aristocrat tibia schism colon= el bigot dissertation shamefaced bivariate wast carbon crescent willful pi= rouse ubiquity celia grandstand employed kibitz incompetent
 
operant tiger edgewise co= nscription quasar breakdown afferent winthrop epoxy reproach buckhorn embr= aceable extinct iniquity alewife canteen reid pack doctrinaire delimitatio= n dampen disastrous mace ca desegregate kaufman literature helsinki=
 
bloat trioxide hardboiled= hurricane nurture boston betroth lockhart smithereens rumble cowpony tara= ntara winy oblivious precocious aniseikonic freakish lila dissociable boon= gamecock bunkmate consign eke abject
 
nurture jacobus bowditch = densitometer orthogonal woe commendatory ph.d pogo abater jocund eli eye c= ummins calder avalanche tristan fence challenge puny reimburse rockland nd= dalhousie barnhard panjandrum inimical mate affinity circumcision renovat= e activism
 
weight ember whitlock abu= sable audiotape margarine derriere pastiche agitate meanwhile burley diffu= se ambling figure colombo baltimorean saltwater eigenvector coffeecup lose= seaquake
 
bundoora die levy trigono= metry stockholder iliad alps astringent internecine aries subtly onomatopo= eia diversionary gloria antioch evensong torsion balboa discriminable unix= poisson homeown adulthood adsorption mary retardant apparatus tootle exul= tation him atrophic
 
cashier couch roast penis= censor harsh sexy amphibology cutout sank edgy swarthmore bureau humphrey= bush counsel omen bakersfield bikini watchmen ear dehydrate chairperson h= arriet aarhus behest bodhisattva hamal bloom dolt
 
behind banshee crossbill = abalone barbital eurydice tag hypnosis febrile wealth pompous forensic pau= la chariot handicapper columbus endogamous prim courage bastion liquor pht= halate gnomon martinique brenner conjugate dianne
 
badminton brother avocati= on ecstatic larsen donahue fallible sway celluloid felicia canopy calder g= oggle birefringent corn cyclorama east servicemen urgency diathesis amnesi= a chaperone bandit jitter nottingham guffaw ferber crematory dickerson com= missary longstanding
 
rummage churchwomen hammo= nd linseed serviceman ahem tweed addenda sol chum tokyo cesare verbatim ca= re airmass jaguar winthrop checkbook cruel
 
bonneville basin polarogr= aphy faery einstein leucine lookout brunt today commandant colloq duffel v= eridic in debar bow pernicious anheuser loy chap hypocritical mohammedan c= atskill caracas hillel procedure babcock michelangelo crankshaft concierge= interim dabble hesitate
 
ghost wag effie flask aug= ite classroom erbium aerosol palsy disco daydream janeiro asperity carruth= ers bodleian elton enigma aileron continuity inquisitor candelabra balfour= drake endosperm jealousy enough afghan pier lincoln footwork attain depar= t kenya chelate batt automatic climatology constellate
 
acyclic seedling commonal= ity austere barbarous grimm capitol chambers bicentennial were sinistral a= urochs leftward declination verandah rattlesnake worth throat planoconvex = adoption implore province selenate celandine durham dyeing dash arginine d= eliver epochal goniometer absorbent gab moriarty ophthalmic duncan jam all= ure council haifa
 
memoranda veal heel hondu= ras agreeing allied cajole glossed officemate caribou real broglie den gar= den cerulean halfway mars gab snakeroot tuft gangster equilibria megaloman= ia offhand ordinal utile counterbalance disyllable counteract passivate tr= ansact ellen talk attitude prohibitive we've malady mylar bid mrs buena br= andeis daunt bearberry
 
afghanistan averred uptur= n weaken congolese cataract kansas intent jugging ri styrofoam denny craze= widget twit smaller abandon camino hearse refrain sudden ti astigmatism f= ormulae escalate oklahoma simmons accredit babylon carboxy synopses fusty = renaissance cufflink stigmata rasp boylston cinder treetop cruddy dunbar a= sthma fundraise bullhead philosopher crossbill geraldine barley basket det= riment blare transplantation riemannian tuberculosis brash is
= --Java.EAZIO.56985454784408013-- --Java.PLPIJ.878982529273788579 Content-Type: image/gif; name="raffia50.gif" Content-Transfer-Encoding: base64 Content-ID: <036975c4d3c0$2180fea0$565aa4c0@ATTYRRFY> Content-Transfer-Encoding: base64 R0lGODlhLAGAANU/AKepw/oEATtDo/Tz86ysrdTV1+3t7fr6+v39AsXFxk1OTwYFBfCek8rL2YmJ j/BiVtra3HR0edvblPLy8d/f4vwyC8bg5oyNyOfnXO/HwcMoJLjKz8fW13V4ofr///7+8+Lz9s7O BOyDeFZWCuTk5pxnZ5aWDE4DA1dYXO/v7/f29jw+QpiapPLZ1a+vc/j4+GFiZSUmJI43NrmMjOWy rff49s/Q0ejo6vX29Lq7x/n5+cPF1a+yyczMzOvr6////yH/C05FVFNDQVBFMi4wAwEAAAAh+QQF SwA/ACwAAAAALAGAAAAG/8CYYkgsGo/IpHLJbDqf0Kh0SoWurtisdsvter/gsPgq9JnP6LR6zW67 3/C4fE6v2+9wA6mx6/v/fTk8g4SFhoeIiYqLjI08OQ4KeJOUlZaXmJlxenyAno6goaKjh5CSmqip qqusdAY3nZ5/pLS1toWmrbq7vL13Bj6xsjuCt8bHjrm+y8zNusAFw37FyNXWuJHO2tvceAbR0sTX 49fK3efo6T4GEOF95PDI5ur09bwGFO478fy38/YAA2LSo6+fQVr/BCpcOOeVsB0PD0oUlZChxYto gPFpsDEBDRoc+eQYSbLkxJODKmJcyTDaRwYPHlQI8MBCggQ9ctoowLOnT/+fIR96KkkNpSKVLJPa s8FjRoCnUGluYEGgKgGSN7PezNnDhtedBSBQGEuWglgKJNKmLcsWgtueNkIOI1oLqdK73b4RYFEi KtQHU6sSxaq1MNevXn+6FUsCrdobN8wYmGwgxYQJllNoTjFZso8baseKZRrK7rkJA3BMAKaGMmu8 2/TkYBGhr1+pgkca5qoTseLFi8mqJQFZcmXOnCtTXuc6DejGZiFEo5gNoIEBPViw6LE644QbYivD 5taAhwMUMm7jJnwYMViewIOXfTwZ+eXUOPLr1z+gP+r+A9x3GWbA3CCaDfuUVl09KZAQwQIQLhDB DawBw0MHGF7QQArjNfP/zQ4ARJLebYBdlcNWifUkXXxsOfZYZMdZ1h8OKqjwwo0v2HijjTX2qF+P NeYX4GqgQVCegqfQk8INKEQYYQQcAnOBAFRWmcMEHfqCTx8hKjCiXyWeiBNY8Z0133CQFbfOZv/R iKMOOL4AZ5w71pgjkHXiMABnoJEGimnNLNmkkxEmMIAPU1apKA9YZvkMCX50+WVUD3CgW1dhtdjY cJymKZl9qPUopw46HHAAqafKOeqcpJK66qg56skZCQVQlyQ6ghLqJAs4JKrooo06ugoskYr4VAXI PlWpmDtJVwBabqH1HHFpesqcZve5uWqppnbbbauntiquuKOqoBqHENiq/06uukbIAgC/xisAo8Kq 8mGxXgZQQUwy0WTpmM/akMBOOOEEQU6vWGsctqhpCy633kbsLarcQmyqq6qxoy6uTLbrZAfyyntl vZps+YekNMm0r78nYkqBwFkVMLDMNiwZWUaT3ZeajXCiGrHFEl98atDh5ogZBRt3wyEMHkeoQMgh j+wDhyRP4hAgKPPb77IAU1CADSt6BQGtNd+8MLYz6tizxEAT7XbFOqgQINJInrN00xA+DXXUFJxI wWtV1wHOycbOROm/PWRK7ZrJ8WlcjJY1rDa4bg9deeWxDkD3nwtqAwzTeOu9d8g8EOBAAVQH3lA7 nqBM4r/NulitpzdDLv9jfpNbXPHlbX87MZxyb55M586o4ADeC6wA8uhQ51AACYCr/gZBsrgOJuyK pxWZmmdQplllM+Lwppy+B937xERDHDcOwjcCaCuvrIA3CsuHfEH98rIQrPRyCMWlsa87Uey0p7Du bQZ8uNPRqnh3uZ+Zb0ftY8T7WJGCAsSgaQooAP5+dQF2bFBRHaAQ/zbBuuoB8Ho5wBRjqLU9nGHr dtpaoOXSJ7QGmk8HNWBf0pyBD/m1SwGg+SCVLrCOCUBAiAJwwAg3ASlpoGxfIjDcslQoO+55j2GS e9OcbPgtnzkQfZbDoQoiuIgJsmIAD9KVAkgwgBsI8QI3oNoEGiBEAKT/bolt8B++ZFABETyAAVFk WVeiRUCzKec42aKR2lTFRS7q7mc1IuNRiBcoCxJKARTAUgoaEK8OkIBDlvEBDjT4K09GD48ZKeEw UCYCfW3NUoMcCwu7Vx824cdON2rVC8BYvhpWTn1si+QOtTGBAsAgBsiMAAmCtcnldYAFn5ya6QyA KQeArAMXoMAdUZmRJoaDlQ/wo7JgCTZZLu5abGpTjea0rUb27nxsi9sYh9kazAQIfAOokH8q9B9g GGA1e5qaf8yQAhqRwAYUMNoZUlCDCjYAAmg7wDHRCIN8GmmZUeLmGvR4sgjk648xmckUM+UYQ9ZS Z4pUVS5H1chfsu13/+uTZCLswg6wXcWIV1kTCWaTA+8lgCpspEAPdpoAHECgKjZYTVh6QAAbqMAG BEgAMDRXlQI0lEM5aGoEVpCCkVynAFUZGwsgcEo8mswdAPBoesSZrErhJHu1i9GAwqfAcZHvbV9s aRfNJVNE2AUHDojBCpAJg8HGoKI2uIICYhCBykRAsMhMQA4gSxXBDtYBEoXsYZG5ABa8IAeKjQGv KIACIQx2BRQdQGAVcIXZFKCsI3yFPrikVppEMVkisMkAifOpdKYNl+Oi3AxnWCqK8bKBc9Jh3doA 2AUQIAXHc0AKWLCAnTjgJk06qnNTAAEYXHcBMDgoYylE3RwcMwE+aP8SAQxwTAisAAVuoW4PAtuD FNhAsCqAgQKmS4DsLMABh9Jo9wbnDtrkS18Z6Fdu37pCGEEukbjUonD12ksaXixWfS0FJdEA2Bjc 4AUJiEEBDjBZnLAWBYuFwGM3YyoCxCABHpisDfaUghg4AAYoUMEBHIDaHb9YsESIAQFQAIMDGOAA W8UBjqG7AgUc0wEqELBk8jHb2dSWJjCZyYIHWJxaRm4CCaxBDXKpy3Dh9cyOBJ5yOXcrNXSYjTL+ bAx6wFoSeMDFJAjsiFVgohjkAMTONZUNOovjCRiPq8abM2OlAwkKFHYCpELBCpQMgwQ4dwAvWIED dCBlM3AUEFY+cEj/n7JlxTkYVL/NEZnLvMuXIjd9bXNV8OjJ4cCSAAcy1gEBFtCDY7IgsJ2FgGBp 898cLCAHh3pyYFdgABQbOrAGSLSDbMyCK9wgxCgg9qRx3APGsoBpCiCrgNkx23cYeEQgJbVuw6I9 xkUufDHcFrlsCE/zxTNHmqP1QiERxwI4AAITsMG/VexkAkQgAkb0KAoIEPDTTeYGLBiCAyigAu1Y BhL/hAT0Iq6Af1smAfp1gMW1M4Ehd5wAld5mbIlVZR6cm9Qw0deWGXPqd+PHTXUN7toqTGFfXoxU Ocz3ctvwT8l055/g++e5BCqjnOlTMzgAhmY+RVAsXQczOJDjnvoD/0oOBSgF+xw3gd0xCNqsAN2B 7KNNTM24ATUM53HSubh67k41G1HfrvDnazrDBr7Lwe/d63uFxu3N2ZZ9q+hOsMzXLpab+faWKqiB AuVt1+O6tHyxBt7c8N7pDt2r5S5H/LEecKwFs5tCiGxTAiMs93lb3vLA/JmsA5SuoXe+XtQrNyHM jm4azETtiZNWZdxOVx7VgFWtdxXQ6o3mA7xKbne3/e2FhaByU4P3o/99bnvAmLYDaPWRRz65KNYz OFm4pXY1F2Zqz+bp457K1t+96GWOLLWXE/Vou7mdJh9cWIVr7vbWUtsSK+vHee6XFJ/2CfJ3dsry e/Y3NpGRf/sRYf8rlXw6R3fqsy1BUoDSd4B3cVagd3gMqC8MUH+5hVAk4H0TqEg8w07Kp0u6RHnn 90DltyOyojEd6IFKkYCgVgjYpy/1p3bPkoLD930JtCN0oioW2Hqt9kvl9zBwci442H46iBcgaHg+ OH99ZIIW8CwUIoFHGHcVqHOUx4Q3BCt2JU9SyH7D02ZVyBI8+AdFEXojGFLIkluNh0jwJip20jOU t2plyISrlnw2+HVT2IZvqBRXqA9z+IPHcocWAIE5o3pAAlw3cgAekImuQmavUlxPSIZLiCPmYohs 6D4blogMEYezYAiO+IgMAAKS+E/FZyOSp2ovoIktkAEt8H8w+IL/48KLnjh+aRgrN3iIpuiGqKgQ i1gQrFhYk1J/ryiJMqJ/+zdmmNgCfsQvKQCMvuiLg1iG32iDssIZtZKDySgQ1Vdu4sCK8wcVyBKN xPFuegJ+NeIBOgATDNACKuABIkAB3Ch3nUiIMJgnekIgPlCOVHiOkxBKj6KOfoAI3zaCj1gBr4gW UwNDLLgjB1AD4TQAmegBByACJOB8oBiD47dAn8hOqmIuBckZB2mACkl0Y9QDL6ByzEF0sNUaY4eF 7CiRQEiRIEABXwh2N5dSrRZOH5mJB/AAFGCPJdmNgZiGm/gC+nEZD4eQiBiTdXAoCVBaBAABUXYG AxBlbBR13SM3/ymoAvuzBrmnjnNYdoWlAVEBjUEJPZpRlDSiSB4AE0n5kf1IkjH4KlEZiCq1IznU knyClceolXQwAAngQxAiWodiALhWWsN2dNNlWDDQAzjgBp/nlhAZl3P5jkH5hW83gbfYAhXQAknp AzTgRyAQiuAoiEnIkl+XmDDZCzl5D4N3B9x1QUR2WBCCbDhAXcmjABASAfk0AWk0WAvwYgHWGizn kIkQkXLpjqSZgmgzgXbiAUj5kTAhAjTQAuIzgMhHmN0YmAQ5JC55A4opQaeIBpchn2u5BgHiA/W5 BqCBBnipGmZJCTcXLDgAGpeRgndgPAuAAh7AYwuaPAdgaX5mKv/ddmx39pwJcAA+8CBcVVbLyIyH YJ2jCZTaSZTcuY+q6QPgWQEF8JFaFJBLCIXneSf8gRl8QisGmAIAwANydAEXkJ9ncAMXAACwIEJt MAE8IADQgw8YsqQZ0gGo4w0TAADXtAOdaQDLc6QC0AE+6gYqoF4LGgMHoGIs0KWd5QFm4AEPEgEe gJwEYKYFJT/IxgaqKIfVKZrYKaJrAm8syI8i8JGqCQEgCSt0ElypIpV2NYBAoifsmTDvWUbxaQY4 kKWdiZ/3cxkFpRr4mTEk0AEAwEkQ8AHAAGb/WVAfcKRJSgFLSiUZIgANoBqiOjX5USH5sZYTcE2J cgGlOi8FQCX/fXAdsYqfq5F1lBk9+VWmgaUC0fYCEPCcN9AjOkABBPAsyKRNZvAC0RWW3eSQ01Cn K3CdE/mKEXiaLHgAA/AArJmJ4QQCPjAA5CKG6XmSSRiDiaqoNPoKNmqOZxCpHTCp39AAN5ADEAAA F1AARnoBOcAZDUABUxKkmcQDQUohE6CwPIqkrDEADTUvH1ADN7ADsMARQVpMPPo3E0ACArsDAgov PPABOPABU0JHAiAIWZoD2iSwADA1HEEBnUoCPPA3HEZdc8agXmdsCuABCeAAEQBNHqACloZaZ8Bn CYqtA6at78Ct3vqT4FqE3OmRCaYDmaiaIcUATlmYgBh3/ZeE/ys5ZkEiJJZao36SlcwlqZAKMhQA NSkrAPdTJS67PN/wK9DTPSQgAACgGjkgAEcENcWkqnY7qZEqAB9AUH8rRBeSpVn6AfWjITEQuDgz KMj0lTayawfnJH5WoQqArQNgbCsAteuwsVKbIIcAACA6kUBpmv25jyIAtpmYAhmgiyLQpyrJKuNj ti1qtjqStuz5PZDRqJOEjBwGt6Ikt3b7ASmQpRPwAVRCvRpCuLlqANA7LyAzvfDSt5Lxt4E7ATsg AKiKpCwrADvwAeWrQR3wAR/wvcCgr5MqSlk6JfD7vFNSAx8AAawKMjlAHAr7pGjAIcAWmZjlswug AL8mPzGgXf85JpZLi7od6g5vOQiua6c/Gbv4xJ1GZq59mYm7G7Yq5YJoOKi9K4ovIHnEu6gFclAG SL9xa77qOwE1YLc5BDLWy0kFQLkcBLg5JL9+C7iqUb7nm0NHegOHO7i/8qQybAYTcL8CkB/PGy85 oMOU8Z9pYAA1+SDI+V/GiVkqwGnIGQHGFsFm4JjJg7rBsLoXzAMZ3K13ysEY2SMeQAMPEMIizLsq uVIrKaglDLyRR4wFOSDf8xkwjK+Qyrw44LwmG6kXkB86bLft68MJsgP+G7g4YKp7J75FbL4gkx/f u8SU/Aj+OsNmGbGAOyVUjKu8+gg7YKVTLBlavFBYogMM6rP/x7MC3eEDKmC6Qku6pgu1bemQbxzH 3hqE4LqduEMj3kkDH3kq4Mm7wPu7g7pIdDK8LKmoxWuviZyQbKCvKruyjgxmidvIjGu3nNQA8cuq 8Ps8k5u+4LsOnky+oDzFODDKu8pJAsC/A3DK+Fm+FyBm0SsABsDKkJy+FAC//hrK6zDA2wQBNuDL gbVLZZygL7BQBWChyVO/TgsDxKxK1JkIyDzHy4xSuOMBCeaRHpACWiMTfWq2fTyV8eoqtSij++Ef NOqSadG2i+kGi1slGEK4L2vOkYzO1jsAVbID+NMHfNvJRDwBg1u4ooykc6S+c6so4DsAvsKr6dvK NeADv+Ky/51JvpdbvylAAYM1Ysd6AE2yy9gacMlzA9PKGtb6X6g7p4CgCCUNuzSgrmDozN+5lw+Q AR/xES2AtsfHib3rgjyjUsZ3J9us09/zwt/stn1XHgCw2TzAB//6NwawA69lAHyQAqJtRCFLvjzK sXN0ATwAATlgNmbwr2SFD7HNB5MB2xSyU5lEskEqbmJZADwKAMv0IZMh2pThsBcQy7hNzzu7dxMg Pw7wpR5gSe7FaxhqAA2qpl4Kq/JjKH67uuuICH29wX89NZcxgSpdASnwkQ8AzUkZN6o2yH5szSs5 yBGGS0ICIDQ2dYi8BzApqrM6n/kExXKEJZgBq6k8q1B8Lv/5WeDrcCjzGeFi6U/6oXKXOqqNkuBF xOATvg617MvGSRsvJj9qumsrUFQDsGvVRWIWmtFe3MvrsJPxR9Kva96AnS02YqYVAN/rDQJjbLZo qypiNmZ9XCeiMt/mss30urad8RxHAs6M6ZnMqSsoEEeqFZkX1FlRluXPeUEitpZ6Tac2rsFBeN74 hIkp4Hu2i659un+iyMK2uMI1MmZIiIR4ItlMDiBre8igQQFRjtlr0B3+fQlFR5k1EqqJngI1YpMB cR058FgSwnBRggMgJ1gR0ANheR1DJlj/Fp0PLd6sS943fubq+k8TcAAJ5kcZkJQZUAE3ADwqDOd3 ciN2Xif/d06BPrLflE0gBfLnPg2fyktQ0YoDPZADOnAoUUI10ZZPNKIcU9PsZ6AD2aECEOddbNQD B+cWB0fAFnEd1F3LY9kj+3MdQLJNn6mti9DXQdjjp24ZfMrSLPreSSvItp7keo7nuT6v88jfB/Tk axHsjjrs60obSpZVB1sAPmAWk0ECYVUVXhMZz3MVHDIBLEBYNuBkEjJoChABiYVMK7AOK1FyCIcK Y76KZS7HG+zuazIB/NjmfvkAQD7n+54jt37nwivZirQfTb7TrPEcgG6AaIQCDlD0EWBwDg9lzCly P3VwDpADNhABIgcDBBB1yIQCAezyh/UgRG9sI7EA4L0S/2BXMoWnrW+Mwa/b7mh+GS/flzAB5JVo i8MripM3edk8r7bJ55baGZYd9IqMnz2wAt11AFEfXqajlhFA9doeAVh/tJFwY7xScvITbkgWAxSw WNTVJDcB9qDeaeQm3mcPx2lv6hfp8gzg4y2QrnrOI/pu83n+2LVZiTz/H3tSr8vx534v5a3RXUyy U4lPAr+GrBDQlSvwlSiQAijWAyjAE6DdwM711gnwWMb2WDDANBB1gCe/rXw9+vX314jEpxkASPS+ +pV406+f33ESJEBSlHyeGQf0o9AR6D9NdBTgADiAch5PG0cfIEYLBA5ChHhgOYzE3mTiiMUcvdUU BUGtUP8k1pM18H3BYfGYXDaf0Wl12EDaveFx+XzHs9/xPAALttIEAioEBWlADFKYdDJERBgyQDxU JCcpJV9UXi4xMzNrMFU8L3EqcUpNcQZSB5hSWg1ev25uSCgoGvJw83IcFNIMJnwmKG4mUigOvwwg fHBIbrwmvAYoSAy+DhKQDEZVBlIGSAYMvHzI187R09XXDCjo3uly8fb6/gIHKwoPmQY8/P05YTqg idSnTZQIVip4SlUqVsWQxSJBy5Y8ebt6nYPlwxobaxs9gmlzbMyrjiDXpVS50lcBeC/hWLRDzw8g fPlAtOLXLdMqcSpShJvETVIphaMSKlRhammphqt0pjj/1NHHLFoQbsnUxYtlSpRdwYYVO6YBTJha adq7qQ/RAB03eOTIkSCBXAJ2Vfg7oCOS3ksHAOdNevSU0wGomBRrJXWjrIkUsGrdmnFsZcuXMYt0 YxZeDrR8at4bpC+xigkZaNBo0SKYjxYZfBygwYB1Bg+rKQw4UKuAhwKxlTYtjKph4sVTOzquFVny HYyZoUeXnq4d586f69nEx5bJgRYVGDF44OGFhwcVPDAA32g8IxY2PESZS8Dg0OEMiyt2BdLx1TrN 7XhuugEJLNAAl6yjwzOZ0hJtkEcOQcSDDMBLbTwdWnjgARoy0DC1Cs5jYIMcKGABgiZSOKCo+1h0 KDFW/0xKTjkIIPgPQAELzFHHy8pKcI4FLWrwpgoe8UGnCStwhIbx0gPxAdQoFOGBDEUYkYAECujh ShVXZNEwVVhZTCrGrLnBh8cgs7E5HHds08112vAxHuxqGhJCRCaYkEkawBOPgSXF05ABETxohAMI CKCgrgNy8EEHo7rE7yn9xKRKFqsgcwnAALmiTsxPQQ1V1FFJLdXUU1FN9dMJqEKjOjnlkEzIm4rU CQcDaMChBQMcyaAFf3xQwYcMcKhhghpSeUGHvWrQYVkvTWmIuFUoPS6M/jJVUzI21WijgG/BDVfc cckt19xz0U1X3XXVtaEHjrqtEdY4ZAXtDztBMBKRGv9aGJSBfxcx4AAcBj7AA09qKDZh4Q7zsuEv 89MPuWsxhUDTTbn1hYAeOO7Y449BDlnkkUku2eSTUT45gQgIAMYXG+alFy0HssN3nwleaKERf6X8 Fdqff34KKkSO++rSqy6+sVONWICMxqehjlrqqamu2uqrsc5aa6xtQCGCVssw4IYeY9Y2FwBorpNW Q2xtQbUMDMighm+APkW4aIdLZdpowqzUJIofs9hsmTJ21QF3U05c8cUZb5xkGwhYAQYIbgBbjDjL fkPWtO9dW18mcPCArxoiSbjuwu52CpVpJzXOb7CxtTiBTeNamp3DHc9d99157wFyLHqo5oxXM9+8 5rX/I8QzmocLY/705oV2sZhqY6zq6MALmB1j27vFvffvwQ//498VSEB4M5TJfAcgg+TcQUFqtXWp TzpRATAdMnHWWcBquAT/FvUGpuW57nVGw572lEaZ2yFOfA10oOPIZz7LsQFBZWOfPNB2PHwUKUKr OEYbUnAmWVADTVeh0bcoUAAI3O1h0XtR3/aDkkvNgjdJWxP3fOG9B+6QhyaL4PnMQLaYXfBsnBsS kfLVwQMVwF28oYUKaUQCCFCjFpeqSrDy5sIXVooxyQCDLKpCkW8NziKFG54OQcYBNa7RYzZY4xs5 0DE4qpGBPZgjG914R5HlMY4c42Mb4Yi4P/qOjYRU/yPIfjjBZIxNfUTEBdquoIEj3kknq5jfJvq3 P/zpby/6c5bp9iY0vhmHUhOD1xetIkXB0c6M6ENjx2xgAxpISVCx9F2gNKQhEdAAcbTM5S7jaIME 5JKYDxCBLItpTAbU0Y+0PKbvlmRMOc7ylwnggA0CdUxs6hKaumRmItG3mcw5Mg+QrJOUHmSIm+mN OKp7XrQcooq9jRJUyIGd9dC0yu0psHvM9F0PHgAIgQbgAQlwY0AHKlARcCABFUgoIBbKARo8VKAJ EAFFCdpHOSI0ABG9KCAMaoOPDjRJFhipNR0KCBpYAKEV2MD4Ilc+IJbEHY3cXCQDYcx0cqSS0ZvW 6v/yBr3oSY+ArugiGa7nNBtuC4eG8ycHOJrQCtiRoxqwB0h7kNKH0kCiGNWAA0Zq1YHy0mNQFWg+ ODBSB5gUowFIjUBnkICBlsACKT0BC7IEy5hKEH01HedN/SAIdMIvX4vhh0/kuQroNc8pE2AdUatV QDPEDgIwY2VTz/jNiQLiBAtYwAkEygCWCtSzoAXEDGxg188K9AEW2GwAOutZz4KVtKs9rUapOtDW qrUAWi0tazmQ0hIwYKAakCtnCVBHcIZNXn+dWSQFu8Ek6mR5T1msUbKoxReNqnpjuB7SlqqVVobt lWkl7QocgALWjhYQJZjBVVGQWs6iAAVXzcFrNSD/A/3KQAEEGKkM3ivQFeSVY2YdKCME6oDXniAG EYDBVYcJCA1ENQAzEGgMELnXmV6ugmVrjjkluZ6dRuiwQoNnwwJ4mKFGTFSmRKX1wJjPMV6Wnzlk poEDMGAIBFfCG6CwQE+gAPkGQAMkGukMXptQEbCVoicYcFkpDKIEE5ezOaDRSFnwUbHCFhAI1YAC COxHDSuSI0KM2YfTG1jwnEcQLZhuWyaVWMT65LFggmxkjfq3WMxwhhOhiMUsu0/qlJejEcgSj4lM gB/DdgHvSakGeGBeQEQgyQOVwQZGOtDOOiDMBtaAaQeqYIHK4NAjpXRCnYxqQ8N0BTIlsw/MPC80 /0NXxG1+M55WLM86a3e7fiPTKWHc51SakIlkvAhmXXnjI1uAoUBWNGmvauiGAkIGOWBvAGCwYNku IAaSDoBtA1AC3OaWyAp4qKipzexrw2DInHUAqgkQZt+NOWyMVN+s1ayhQbiZIyROTJznvOIXTo9o n9LznvvjZ4WjKVPuQuANa+zU8eXgrH/i6Al4wFEFyAC40ybyDEZ6glNTuwQlL7lIBaoA9XZ53J5m AcdD3VuFzhLIEYCAVgMQgw3gPAYGZbWrwybO4gE2xPq2tZnE9O9cC5BaReViDC313YUzfDkndBc5 jx3xzKYR5g9lMI4dsIGr0iCrGG10pQfag5GK+/+qDMCtpwlAgKsGwAEQKEFbGw2Bqq4AApl+8s/5 SgbM3fumCgjxYCvAGjMlT3lNH/jjYVi07qJy6hSpxeWr/rRvORzruRiv4F/ZgwKwANRAXoDNOeoA Cty9y2VPqAa43QO0J3jtEHi3TeoIdwpEINQQyMEJ5k7kBazAjlSGrc0JIFANwEDe82514EsidA8X /vAiGATlFs945UHe6fsZU2MQrnDMY95q4XJ4XWg8aH+KPgKfPcH7PRvfAhAA/jZPQAzef4IElCD/ 8Od2vHtABvqv/2AgAfKP+aQg/5KrYwpgBuAPAFeg/r6FBUrL/2IguYQp/xYg3mxAADsLrzLs+Tb/ TCT8auiey/COCAImIvtK5RXGxOBiJOpmYdgs7/KkhlxiKQcRhy7kIv3QwQBCj2NGTwGeIAYU4HBi KQdWgAu+xQmegAC2oAhjYAUiIAeypAAiQAql8HCIEAomsAg5DZZ4YAlXILnmbwljAATnDwaKkAqx RAjZ0AiF0AlXIAf8abloSn00h/pSkBZWUCRiMBCNJuHEj+qcRvPGRQdtCWToggd7UNB+MAiFMEsS QPTCDFwECVx8BwdhqVzcBRP9CBQ/RhNDcfM6MXuwhIk8JlxOsfnETAQVKX30cNYU4IgqYIpqwc/A aBfNhM8I0RAzDxHNTwc/phLpgmMaMRkbUS4e/zGB1M+HeigaxQcPL6e5TJBB0izEbuJbcDEXK8/P xs8GbxAHFTEHfUeQOkYZeyAZmTHu3BEAfFAjJFEa6bGBqJENrHH6ZqYPVkAGtFEQCuCauJFGwrEg D1EYh3EHlbEucsAd444FINIBjsABKJIIHAwGMBIG6AsFYCACWAAeIVEemagcSbIkTfIkUTIlVXIl WfIkzxDoBC8fh6heIuAKpqAfQywgB5JqMHER13EZG9IdIXIoKdIBLPIiNXIjFWApb7IpnXIKljIq YUAiaad2tM6VsocZtXIrubIrvfIrwTIsxXIsyXIsE4AFYDFsOsyCPowFHAwFFKApZYAA4qIdHf9y KCOyIi0yIzGSvqLyKQEzKpdyI+mLLzHyKI+yA4pSIkEyJNmBCAQzMiVzMimzMi3zMjEzMzVzMwXT CKGPw/RwfQBkD47AweLyJglTMgHzKSOTMDmSLxHTIhVzMWkTL20TIgEgN3WzMR3TF1LACbYtOIVz OImzOI3zOJEzOZVzObetwT6TgkKz8x5pDxygA96yNQnTMDsyNomANmvzNvFyN8VzPKsyHs8BUZBS O9VzPdmzPd3zPeEzPuWTPT3SBkYwGdZyJsszNyfSO78TPIdyPAU0N8uzQAv088iABAogKB2yQR30 QSE0QiV0Qim0Qi30QuMuASgHffJzXqSTQQZ+NEQNdERJ1DzXgIa2JkVVdEVZtEWzZhiGp0Nh5UNL tEZt9Eaz7k10dEdjNDSNDUeBNEhtFEF5tEgNREZhRUiVdEmHFNmM9EkJ5EB8lEmptEpNFEqxNEpl 8systEu9FBeINEvFVCxkcRa/9Ey9NEzHdE1XokwJD03hlEl3IQgAACH5BAUKAD8ALBoAYgBqAA4A AAb/wJ/w1ygah7+ecdkYMos95POonCKR1aYwK2VGk0dwcRtO9iSYNEbSi57VaolEC0+zm+06/F2X f7Foa26BGE5ycUp8bIpJgRJbPxgIk5QYbQ2SlJoYDT2amnMNEp+aP6OkCJxXmJShpwhmmZ9zr0qy c5kYOUSyISGVvJQmJr+TUaiTtJq+vyGmwsStWkKslEqnzqLLmj0JlC6e39UjRK8mQibSmc4/I9/h COcjxZyv5EgR2EIx4lKyqdoQsKMUIkY7eg2+vUoFj1xAWD8i/EC4LoKLYiFg/BD2Q0G6Sc8mDRsZ AQA2i8UQoLDhb5Y+e0JQfESQI5OLfwiwrUhQzRnL/548cFIiV0AYDwjYCCzc9PDTvZYCK01y9moF jx8FkmJr9nEdNa9fRbLoNVRIUZEEAoZw8IqZLxg52pa9EizezKkhEcD4iY3tJxPuNJ0rJ66TsLF4 MTqwAc8EgJ55DSLZ8SrGxxARpoWNN3FZXhdGwDrdqGkEiyTeJq1BMxSAVxiVDIt0YQ6GORe4cZ/B C1u15rrnIniO1KqHLBMwCvz7EVTTil1E7gqu6yxHymOonPlFZqPvjpRzoJ5jMdNZARfI2CkniLXt FQfzlg1eL/AHBPSqSX8q+IMyMlgnFcBCSqtkYgILEHRWXwE8xDedQQ8RlRpnV2gUwwgYImFDAiPE IEdZOx6S44KHJH6IFQwllviDDR1+iEKIV9jgQotDKEDiEA78cCGGJrZB4xA/0nXFCkIWaSQSGhlJ 5JFIEGDikSgM8WSREl0RBAA7 --Java.PLPIJ.878982529273788579-- From isis-wg-bounces@ietf.org Wed Mar 23 09:51:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21297 for ; Wed, 23 Mar 2005 09:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE78I-0008SV-8M; Wed, 23 Mar 2005 09:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE78H-0008R0-6j; Wed, 23 Mar 2005 09:46:53 -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 JAA20589; Wed, 23 Mar 2005 09:46:49 -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 1DE7Dj-00085x-9U; Wed, 23 Mar 2005 09:52:31 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 8A7213DCCAD; Wed, 23 Mar 2005 06:46:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d0e7e1010295221c425a17b7d2d6a22@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Wed, 23 Mar 2005 06:46:39 -0800 To: ISIS WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: [Isis-wg] Fwd: I-D ACTION:draft-chopps-isis-bfd-tlv-00.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 For some reason the announcement didn't make it to the isis-wg list. After some time for initial review I would like to propose this become a working group document. Chris. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 21, 2005 12:31:51 PM PST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-chopps-isis-bfd-tlv-00.txt > Reply-To: internet-drafts@ietf.org > X-Spam-Level: > X-Spam-Status: No, score=-2.6 required=2.0 tests=AWL,BAYES_00, > MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IS-IS BFD Enabled TLV > Author(s) : C. Hopps > Filename : draft-chopps-isis-bfd-tlv-00.txt > Pages : 6 > Date : 2005-3-21 > > This document describes a TLV for use in the IS-IS routing protocol > that allows for the proper functioning of the Bidirectional > Forwarding Detection protocol (BFD). There exists certain scenarios > in which BFD will fail to detect a forwarding plane failure without > use of either this TLV or some other method. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chopps-isis-bfd-tlv-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-chopps-isis-bfd-tlv-00.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-chopps-isis-bfd-tlv-00.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. > Content-Type: text/plain > Content-ID: <2005-3-21154226.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Mar 23 16:36:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12761 for ; Wed, 23 Mar 2005 16:36:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DED9L-00020M-VZ; Wed, 23 Mar 2005 16:12:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DED9G-0001zW-6P; Wed, 23 Mar 2005 16:12:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05278; Wed, 23 Mar 2005 16:12:15 -0500 (EST) Message-Id: <200503232112.QAA05278@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Mar 2005 16:12:15 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-09.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 --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 : M-ISIS: Multi Topology (MT)Routing in IS-IS Author(s) : T. Przygienda, et al. Filename : draft-ietf-isis-wg-multi-topology-09.txt Pages : 12 Date : 2005-3-23 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-wg-multi-topology-09.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-wg-multi-topology-09.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: <2005-3-23164403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164403.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From isis-wg-bounces@ietf.org Wed Mar 23 16:55:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23020 for ; Wed, 23 Mar 2005 16:55:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDgI-0008Hy-2k; Wed, 23 Mar 2005 16:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDgE-0008H2-7y for isis-wg@megatron.ietf.org; Wed, 23 Mar 2005 16:46:24 -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 QAA16605 for ; Wed, 23 Mar 2005 16:46:19 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDlg-0006Vf-Fa for isis-wg@ietf.org; Wed, 23 Mar 2005 16:52:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2005 13:46:04 -0800 Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2NLk23S018885 for ; Wed, 23 Mar 2005 13:46:02 -0800 (PST) Message-ID: <4241E39A.5010906@cisco.com> Date: Wed, 23 Mar 2005 13:46:02 -0800 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-09.txt References: <200503232112.QAA05278@ietf.org> In-Reply-To: <200503232112.QAA05278@ietf.org> Content-Type: multipart/mixed; boundary="------------030309010809040407010200" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 This is a multi-part message in MIME format. --------------030309010809040407010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi working-group, We have updated the M-ISIS draft, the main change is to remove the wording of aligning isis L1/L2 boundary for all topologies. A diff is attached, please send comments if you have any. thanks. - Naiming Internet-Drafts@ietf.org wrote: > 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 : M-ISIS: Multi Topology (MT)Routing in IS-IS > Author(s) : T. Przygienda, et al. > Filename : draft-ietf-isis-wg-multi-topology-09.txt > Pages : 12 > Date : 2005-3-23 > > This draft describes an optional mechanism within ISIS used today > by many ISPs for IGP routing within their clouds. This draft > describes how to run within a single ISIS domain a set of > independent IP topologies that we call Multi-Topologies (MTs). > This MT extension can be used for variety of purposes such as an > in-band management network ``on top'' of the original IGP topology, > maintain separate IGP routing domains for isolated multicast or > IPv6 islands within the backbone, or force a subset of an address > space to follow a different topology. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt > --------------030309010809040407010200 Content-Type: text/plain; name="m-isis-diff-08-09.txt" Content-Disposition: inline; filename="m-isis-diff-08-09.txt" Content-Transfer-Encoding: 7bit *** draft-ietf-isis-wg-multi-topology-08.txt Wed Mar 16 19:15:21 2005 --- draft-ietf-isis-wg-multi-topology-09.txt Fri Mar 18 11:36:38 2005 *************** *** 1,9 **** Network Working Group Tony Przygienda (Xebeo) Internet Draft Naiming Shen (Cisco) ! Nischal Sheth (Juniper) March 2005 Expires: September 2005 M-ISIS: Multi Topology (MT) Routing in IS-IS --- 1,9 ---- Network Working Group Tony Przygienda (Xebeo) Internet Draft Naiming Shen (Cisco) ! Nischal Sheth (Juniper) March 2005 Expires: September 2005 M-ISIS: Multi Topology (MT) Routing in IS-IS *************** Internet Draft M-ISIS *** 82,94 **** advertise it in the new TLV. Thus not including such a TLV in the IIH implies MT ID #0 capability only. Through this exchange of MT capabilities, a router is able to advertise the IS TLVs in LSPs with common MT set over those adjacencies. - As a simplifying side-effect, boundaries between levels will be the - same for all MTs. - In the case of adjacency contains multiple MTs on an interface, and if there exists overlapping IP address space among the topologies, additional mechanism MAY be used to resolve the topology identity of the incoming IP packets on the interface. --- 82,91 ---- *************** Internet Draft M-ISIS *** 96,110 **** Adjacencies on point-to-point interfaces are formed as usual with ISIS routers not implementing MT extensions. If local router does not participate in certain MTs, it will not advertise those MTIDs in it's IIHs and thus will not include that neighbor within it's ! topology based LSPs. On the other hand, if a MTID is not ! detected in remote side's IIHs, the local router MUST NOT include ! that neighbor within it's MT LSPs. The local router SHOULD NOT form ! adjacency if they don't have at least one common MT set over the ! interface. 5.2. Forming Adjacencies on Broadcast Interfaces On a LAN, all the routers on the LAN which implement the MT extension MAY advertise their MT capability TLV in their IIHs. --- 93,106 ---- Adjacencies on point-to-point interfaces are formed as usual with ISIS routers not implementing MT extensions. If local router does not participate in certain MTs, it will not advertise those MTIDs in it's IIHs and thus will not include that neighbor within it's ! LSPs. On the other hand, if a MTID is not detected in remote ! side's IIHs, the local router MUST NOT include that neighbor ! within it's LSPs. The local router SHOULD NOT form adjacency if ! they don't have at least one common MT set over the interface. 5.2. Forming Adjacencies on Broadcast Interfaces On a LAN, all the routers on the LAN which implement the MT extension MAY advertise their MT capability TLV in their IIHs. *************** Internet Draft M-ISIS *** 153,166 **** pseudo-node LSP construction. 7. MTs and Overload, Partition and Attached Bits ! As stated earlier, all MTs share the same set of L1-L2 boundaries ! and NETs. However, a router could for each of the MTs become ! potentially partitioned, overloaded and attached independently. ! To prevent unnecessary complexity, MT extensions does not support partition repair. The overload, partition and attached bits in LSP header only reflect the status of the default topology. Attached bit and overload bit are part of the MT TLV being distributed within a node's LSP fragment zero. Since each adjacency --- 149,161 ---- pseudo-node LSP construction. 7. MTs and Overload, Partition and Attached Bits ! A router could for each of the MTs become potentially ! partitioned, overloaded and attached independently. To prevent ! unnecessary complexity, MT extensions does not support partition repair. The overload, partition and attached bits in LSP header only reflect the status of the default topology. Attached bit and overload bit are part of the MT TLV being distributed within a node's LSP fragment zero. Since each adjacency --------------030309010809040407010200 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --------------030309010809040407010200-- From apache@d257v21.galois.com.cnri.reston.va.us Mon Mar 28 09:31:52 2005 Received: from d257v21.galois.com ([66.49.180.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19977 for ; Mon, 28 Mar 2005 09:31:52 -0500 (EST) Received: (from apache@localhost) by d257v21.galois.com (8.11.6/8.11.6) id j2SENCx07771; Mon, 28 Mar 2005 07:23:12 -0700 Date: Mon, 28 Mar 2005 07:23:12 -0700 Message-Id: <200503281423.j2SENCx07771@d257v21.galois.com> To: admin@openingthebox.org Subject: Urgent notification. From: clemsoncole X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Content-Transfer-Encoding: 7bit FROM: THE LOTTERY COORDINATOR, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT. Email:cole_clemson03@hotmail.com clemson4@web-mail.com.ar Tel:+4401179745637 1ST APRIL 2005 DRAWS RESULTS/ WINNING NOTICE: We are pleased to inform you of the announcement, winners of the GOLDEN GAMES LOTTERY COORDINATOR PROGRAMS held on 1ST APRIL 2005, You / your company, attached to ticket number 14980059290494, with serial number A025-09 drew the lucky numbers 30-50-01-31 -10-2789, and consequently won in category C. You have therefore been approved for a lump sum pay out of 900.000 Pounds in cash credited to file REFNO. UKLl341736GG and Batch No. UKlFI-B. This is from total prize money of #5,400,000 (Five Million Four Hundred Thousand Pounds) shared among the six(6)international winners in the category B. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America,AFRICA as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a FAIR INVESTMENT COMPANY. and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes #1.3 Pounds International lotto. To begin your claim, please contact your claims officer immediately: MR, COLE CLEMSON, FOREIGN DEPARTMENT MANAGER, FAIR INVESTMENT COMAPNY. TEL-4401179745637. EMAIL: cole_clemson03@hotmail.com NOTE:For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claim agent not later two weeks from the receipt of this mail.After this date all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, LOTTERY COORDINATOR GOLDEN GAMES LOTTERY, 2, Monck Street, SW1P 2BQ. United Kingdom Fax. 440207 211 1750. Note: Do reply to my private boxes: cole_clemson03@hotmail.com cclemson4@web-mail.com.ar ___________________________________________________________________________