From isis-wg-admin@spider.juniper.net Mon Apr 1 22:42:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25173 for ; Mon, 1 Apr 2002 22:42:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g323S0t57461; Mon, 1 Apr 2002 19:28:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g323RPt57449 for ; Mon, 1 Apr 2002 19:27:25 -0800 (PST) (envelope-from mjyang@etri.re.kr) Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 18:40:37 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC0889EA24@cms1.etri.re.kr> From: mjyang@etri.re.kr To: isis-wg@spider.juniper.net Subject: [Isis-wg] IS-IS network size MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D961.458F2A30" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 1 Apr 2002 18:40:34 +0900 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D961.458F2A30 Content-Type: text/plain; charset="euc-kr" Hi, All I have following questions about IS-IS network size practically. 1. How many nodes(or routing entries) in one IS-IS area? I want to know recommended number of nodes(routing entry) in one area establishing IS-IS network. Also, I need reference text or reference document about it. 2. Must Level2 router accomodate whole rouing entries in one AS? That is, maximum routing entry of Level 2 router is (number of nodes(routing entry) in one area) * (number of area in one AS) ? Thanks in advance.. -------------------------------------- Mijeong Yang Internet Technology Department, ETRI Tel) 042-860-4922 Email) mjyang@etri.re.kr -------------------------------------- ------_=_NextPart_001_01C1D961.458F2A30 Content-Type: text/html; charset="euc-kr" [Isis-wg] IS-IS network size

Hi, All
 
I have following questions about IS-IS network size practically.
1. How many nodes(or routing entries) in one IS-IS area?
   I want to know recommended number of nodes(routing entry) in one area
   establishing IS-IS network.
   Also, I need reference text or reference document about it.
 
2. Must Level2 router accomodate whole rouing entries in one AS?
  That is, maximum routing entry of Level 2 router is
(number of nodes(routing entry) in one area) * (number of area in one AS) ?
 
Thanks in advance..
--------------------------------------
Mijeong Yang

Internet Technology Department, ETRI
Tel) 042-860-4922
Email) mjyang@etri.re.kr
--------------------------------------
 

------_=_NextPart_001_01C1D961.458F2A30-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 1 22:56:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25331 for ; Mon, 1 Apr 2002 22:56:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g323hht57567; Mon, 1 Apr 2002 19:43:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g323dQt57534 for ; Mon, 1 Apr 2002 19:39:26 -0800 (PST) (envelope-from mjyang@etri.re.kr) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g318vb675488 for ; Mon, 1 Apr 2002 00:57:37 -0800 (PST) X-JNPR-Received-From: outside Received: from cms1.etri.re.kr ([129.254.16.11]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Apr 2002 00:54:11 -0800 Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 17:53:57 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC0889EA23@cms1.etri.re.kr> From: mjyang@etri.re.kr To: isis-wg@juniper.net Subject: [Isis-wg] IS-IS network size MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D95A.C1DBDC20" X-OriginalArrivalTime: 01 Apr 2002 08:54:11.0452 (UTC) FILETIME=[CAB973C0:01C1D95A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 1 Apr 2002 17:53:56 +0900 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D95A.C1DBDC20 Content-Type: text/plain; charset="euc-kr" Hi, All I have following questions about IS-IS network size practically. 1. How many nodes(or routing entries) in one IS-IS area? I want to know recommended number of nodes(routing entry) in one area establishing IS-IS network. Also, I need reference text or reference document about it. 2. Must Level2 router accomodate whole rouing entries in one AS? That is, maximum routing entry of Level 2 router is (number of nodes(routing entry) in one area) * (number of area in one AS) ? Thanks in advance.. -------------------------------------- Mijeong Yang Internet Technology Department, ETRI Tel) 042-860-4922 Email) mjyang@etri.re.kr -------------------------------------- ------_=_NextPart_001_01C1D95A.C1DBDC20 Content-Type: text/html; charset="euc-kr" [Isis-wg] IS-IS network size

Hi, All

I have following questions about IS-IS network size practically.
1. How many nodes(or routing entries) in one IS-IS area?
   I want to know recommended number of nodes(routing entry) in one area
   establishing IS-IS network.
   Also, I need reference text or reference document about it.

2. Must Level2 router accomodate whole rouing entries in one AS?
  That is, maximum routing entry of Level 2 router is
(number of nodes(routing entry) in one area) * (number of area in one AS) ?

Thanks in advance..
--------------------------------------
Mijeong Yang

Internet Technology Department, ETRI
Tel) 042-860-4922
Email) mjyang@etri.re.kr
--------------------------------------

------_=_NextPart_001_01C1D95A.C1DBDC20-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 03:09:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09388 for ; Tue, 2 Apr 2002 03:09:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g327Jht58619; Mon, 1 Apr 2002 23:19:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g327DHt58585 for ; Mon, 1 Apr 2002 23:13:17 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2B9B2WBG>; Tue, 2 Apr 2002 02:24:18 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'jparker@axiowave.com'" Cc: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Doubts in Circuit Level Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 02:23:58 -0500 Jeff, Following are the doubts i have in Ckt Level Table and Ckt Table 1. Circuit Level table doesn't have "L1L2" as the index ? . what is the index for Level Table when p-t-p circuit is configured as l1l2 IS ? (We have AdjacencyUsage with the option of "l1l2" when the ckt is p-t-p (in Adjacency Table) ) 2. isisCircLevelCircID is removed from the draft-ietf-isis-wg-mib-07.txt . Circuit ID are level specific, as local ID are level specific (I guess , local ID moved to Level specific table). I feel, only isisCircPtToPtCircID should be removed (as the reason says duplication of p-t-p ckt ID field) 3. why there is separate isisCircPtToPtCircID in the circuit table ?. Since it was there in Level table, same "isisCircLevelCircID" can be used as "p-t-p ckt ID" when the circuit is p-t-p for that level Thanks, ~ Swaminathan _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 03:19:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09596 for ; Tue, 2 Apr 2002 03:19:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3280Wt58836; Tue, 2 Apr 2002 00:00:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g327a6t58716 for ; Mon, 1 Apr 2002 23:36:06 -0800 (PST) (envelope-from leontsinis@hotmail.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g327l7693916 for ; Mon, 1 Apr 2002 23:47:07 -0800 (PST) X-JNPR-Received-From: outside Received: from hotmail.com ([216.33.240.47]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Apr 2002 23:39:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 23:40:44 -0800 X-Originating-IP: [213.16.148.149] From: "Nikos Leontsinis" To: , Subject: Re: [Isis-wg] IS-IS network size MIME-Version: 1.0 X-Mailer: MSN Explorer 7.00.0021.1900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0000_01C1DA32.D54B8200" Message-ID: X-OriginalArrivalTime: 02 Apr 2002 07:40:44.0919 (UTC) FILETIME=[B2A3A070:01C1DA19] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 10:40:40 +0300 ------=_NextPart_001_0000_01C1DA32.D54B8200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message ----- From: mjyang@etri.re.kr Sent: 02 April 2002 07:04 To: isis-wg@juniper.net Subject: [Isis-wg] IS-IS network size Hi, All =20 I have following questions about IS-IS network size practically. =20 1. How many nodes(or routing entries) in one IS-IS area? =20 I want to know recommended number of nodes(routing entry) in one area =20 establishing IS-IS network. =20 up to 450 nodes in one area you are safe. I haven't tested it though as t= here are very few networks out there (less than 5) with this size. Such a= deployment assumes a number of around 3000 nodes in total. =20 Also, I need reference text or reference document about it. a good book is isis network design solutions cisco press I bought it rece= ntly =20 2. Must Level2 router accomodate whole rouing entries in one AS? =20 i don't understand the question. You are using IGP to route taffic in you= r AS ONLY. That is, maximum routing entry of Level 2 router is =20 (number of nodes(routing entry) in one area) * (number of area in one AS)= ? =20 Thanks in advance.. =20 -------------------------------------- =20 Mijeong Yang =20 Internet Technology Department, ETRI =20 Tel) 042-860-4922 =20 Email) mjyang@etri.re.kr =20 -------------------------------------- Get more from the Web. FREE MSN E= xplorer download : http://explorer.msn.com ------=_NextPart_001_0000_01C1DA32.D54B8200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
<= DIV> 
=
----- Original Message -----
From: mjyang@etri.re.kr
Sent: 02= April 2002 07:04
To: isis-w= g@juniper.net
Subject: [Isis= -wg] IS-IS network size
 

Hi, All

I have following questions about IS-IS network size practically.=
1. How many nodes(or routing entries) in one I= S-IS area?
   I want to know recommen= ded number of nodes(routing entry) in one area
=    establishing IS-IS network.

up to 450 nodes i= n one area you are safe. I haven't tested it though as there are very few= networks out there (less than 5) with this size. Such a deployment assum= es a number of around 3000 nodes in total.


&nb= sp;  Also, I need reference text or reference document about it.

a good book is isis network design solutions cisco press I bou= ght it recently 

2. Must Level2 router accomod= ate whole rouing entries in one AS?

i don't understan= d the question. You are using IGP to route taffic in your AS ONLY.


  That is, maximum routing entry of Level 2 rout= er is
(number of nodes(routing entry) in one ar= ea) * (number of area in one AS) ?

 

Thanks in advance..
---------------------= -----------------
Mijeong Yang

<= FONT size=3D2>Internet Technology Department, ETRI
Tel) 042-860-4922
Email) mjyang@etri.re.kr
--------------------------------------


Get more from the Web. F= REE MSN Explorer download : http://ex= plorer.msn.com

------=_NextPart_001_0000_01C1DA32.D54B8200-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 03:35:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09882 for ; Tue, 2 Apr 2002 03:35:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g328MWt58968; Tue, 2 Apr 2002 00:22:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web13203.mail.yahoo.com (web13203.mail.yahoo.com [216.136.174.188]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g3281rt58848 for ; Tue, 2 Apr 2002 00:01:53 -0800 (PST) (envelope-from dasnabendu@yahoo.com) Message-ID: <20020402081254.31168.qmail@web13203.mail.yahoo.com> Received: from [203.200.20.226] by web13203.mail.yahoo.com via HTTP; Tue, 02 Apr 2002 00:12:53 PST From: nabendu das To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] confusion about minLSPTransmissionInterval Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 00:12:53 -0800 (PST) hi list, confusion about minLSPTransmissionInterval. in ISO-10589 7.3.14.3 , "The Update Process scans the Link State Database for Link Stat PDUs with SRMflags set. when one is found, provided the timestamp lastSent indicates that it was propagated no more recently than minimumLSPTransmissionInterval, the IS shall a) transmit it on all circuits with SRMflags set, and b) update lastSent." now here it is not being told whether above mentioned check is for P2P link or Broadcast link, Do we need to check this for p2p as well as for LAN case???? or minimumBroadcastLSPTransmissionInterval takes care of that, and if so " how does minimumBroadcastLSPTransmissionInterval controls how fast we send back-to-back LSPs as per the new MIB(isisCircLevelLSPThrottle)???? is it like the way as stated in ISO 10589 in 7.3.15.6, as "as IS is permitted to transmit a small no of LSPs with a shorter seperation interval, provided that no more than 1000/minimumLSPTransmissionInterval LSPs are transmitted in any one second period."???????? and again in 7.3.15.5, " an IS shall perform the folln every minimumLSPTransmissionInterval - for all p2p circuits c transmit all LSPs that have SRMflags set on circuit C." and below that " the interval between two consecutive transmission of the same LSP shall be at least minimumLSPTransmissionInterval" the question is if the IS shall perform the action as stated in 7.3.15.5 for every minimumLSPTransmissionInterval, then the interval between two consecutive transmission of the same LSP will be at least minimumLSPTransmissionInterval anyway. so why that has again been stated.??? Plz help. thanking in advance. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://http://taxes.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 05:30:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11519 for ; Tue, 2 Apr 2002 05:30:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32AAot59478; Tue, 2 Apr 2002 02:10:50 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g329d5t59324 for ; Tue, 2 Apr 2002 01:39:05 -0800 (PST) (envelope-from mjyang@etri.re.kr) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g329o7n65146 for ; Tue, 2 Apr 2002 01:50:07 -0800 (PST) X-JNPR-Received-From: outside Received: from cms1.etri.re.kr ([129.254.16.11]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 2 Apr 2002 01:42:30 -0800 Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 18:42:15 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC0889EA29@cms1.etri.re.kr> From: mjyang@etri.re.kr To: leontsinis@hotmail.com Cc: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA2A.AB8A3E50" X-OriginalArrivalTime: 02 Apr 2002 09:42:30.0359 (UTC) FILETIME=[B5054E70:01C1DA2A] Subject: [Isis-wg] =?euc-kr?B?W8i4vcVdIFJlOiBbSXNpcy13Z10gSVMtSVMgbmV0d29yayBzaXpl?= Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 18:42:14 +0900 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA2A.AB8A3E50 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Thank you for your reply.. My second question means that A level2 router receives all routing entries from all level1 routers in = my area, then, the level2 router receives all routing entries from all level 2 routers in my AS in the worst case. So, maximum routing entry of Level 2 router is=20 (number of nodes(routing entry) in one area) * (number of area in one = AS). Is it right? Thaks in advance.. Yang.. =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: Nikos Leontsinis[leontsinis@hotmail.com] =B9=DE=B4=C2=BB=E7=B6=F7: mjyang@etri.re.kr; isis-wg@juniper.net =C1=A6=B8=F1: Re: [Isis-wg] IS-IS network size =B9=DE=C0=BA=B3=AF=C2=A5: 2002/04/02 =C8=AD 16:40 ----- Original Message ----- From: mjyang@etri.re.kr Sent: 02 April 2002 07:04 To: isis-wg@juniper.net Subject: [Isis-wg] IS-IS network size Hi, All I have following questions about IS-IS network size practically.=20 1. How many nodes(or routing entries) in one IS-IS area?=20 I want to know recommended number of nodes(routing entry) in one = area=20 establishing IS-IS network. up to 450 nodes in one area you are safe. I haven't tested it though as there are very few networks out there (less than 5) with this size. = Such a deployment assumes a number of around 3000 nodes in total. Also, I need reference text or reference document about it. a good book is isis network design solutions cisco press I bought it recently=20 2. Must Level2 router accomodate whole rouing entries in one AS? i don't understand the question. You are using IGP to route taffic in = your AS ONLY. That is, maximum routing entry of Level 2 router is=20 (number of nodes(routing entry) in one area) * (number of area in one = AS) ? Thanks in advance..=20 --------------------------------------=20 Mijeong Yang=20 Internet Technology Department, ETRI=20 Tel) 042-860-4922=20 Email) mjyang@etri.re.kr=20 -------------------------------------- Get more from the Web. FREE MSN Explorer download : = http://explorer.msn.com ------_=_NextPart_001_01C1DA2A.AB8A3E50 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C8=B8=BD=C5] Re: [Isis-wg] IS-IS network size

Thank you for your reply..

My second question means that

A level2 router receives all routing entries from all = level1 routers in my area,
then, the level2 router receives all routing entries = from all level 2 routers in my AS in the worst case.
So, maximum routing entry of Level 2 router is =
(number of nodes(routing entry) in one area) * = (number of area in one AS).

Is it right?

Thaks in advance..
Yang..


=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Nikos = Leontsinis[leontsinis@hotmail.com]
=B9=DE=B4=C2=BB=E7=B6=F7: mjyang@etri.re.kr; = isis-wg@juniper.net
=C1=A6=B8=F1: Re: [Isis-wg] IS-IS network = size
=B9=DE=C0=BA=B3=AF=C2=A5: 2002/04/02 =C8=AD = 16:40



----- Original Message -----
From: mjyang@etri.re.kr
Sent: 02 April 2002 07:04
To: isis-wg@juniper.net
Subject: [Isis-wg] IS-IS network size
Hi, All
I have following questions about IS-IS network size = practically.
1. How many nodes(or routing entries) in one IS-IS = area?
   I want to know recommended number of = nodes(routing entry) in one area
   establishing IS-IS network.
up to 450 nodes in one area you are safe. I haven't = tested it though as there are very few networks out there (less than 5) = with this size. Such a deployment assumes a number of around 3000 nodes = in total.

   Also, I need reference text or reference = document about it.
a good book is isis network design solutions cisco = press I bought it recently
2. Must Level2 router accomodate whole rouing = entries in one AS?
i don't understand the question. You are using IGP = to route taffic in your AS ONLY.

  That is, maximum routing entry of Level 2 = router is
(number of nodes(routing entry) in one area) * = (number of area in one AS) ?

Thanks in advance..
--------------------------------------
Mijeong Yang
Internet Technology Department, ETRI
Tel) 042-860-4922
Email) mjyang@etri.re.kr
--------------------------------------


Get more from the Web. FREE MSN Explorer download : = http://explorer.msn.com

------_=_NextPart_001_01C1DA2A.AB8A3E50-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 13:19:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26816 for ; Tue, 2 Apr 2002 13:19:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32I6Wt62153; Tue, 2 Apr 2002 10:06:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32HaQt62005 for ; Tue, 2 Apr 2002 09:36:26 -0800 (PST) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:47:29 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2D18@entmail.gnilink.com> From: "Martin, Christian" To: "'stefano previdi'" , Hannes Gredler Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 12:47:20 -0500 Taking it to the WG... To clarify me earlier post wrt to adding additional information. When we originally wrote the draft, we were considering adding 64 byte ACSII remarks. Were we all able to have our cake and eat it too, this would be a good thing. Tony Li was concerned that adding too much information would result in wasted LSP space and faster LSP-space exhaustion (with the corresponding scale-reduction effect). Hannes, can you clarify the scenario you are presenting? From a 2547bis perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC environment is required. Thx, chris -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: Tuesday, April 02, 2002 8:16 AM To: Hannes Gredler Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; nsheth@juniper.net; yakov@juniper.net; danny@tcb.net Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 personally, I have no problems with 64 bits. I just think it's not a good idea to make a generic rule just because one particular specific case (that can be solved with 32bits anyway). If the WG is fine with it, I'm fine too. So, please send your comments to the group. s. On Monday 01 April 2002 22:33, Hannes Gredler wrote: > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > | > | > Hannes, > | > | > > | > | > Danny McPherson suggested this some time back. We chose to > | > | > stay at 32 bits to be comparable to OSPF tags, but the > | > | > addition of a 64 bit tag makes sense. > | > | > | > | it's the redistribution of BGP routes into isis that doesn't > | > | make > | > | a lot of sense to me. > | > > | > stefano, > | > > | > in native v4 routing i'd agree 100%- however there are > | > interprovider CoC scenarios where redistributing remote-AS PE > | > routers into ISIS/LDP is the only way to get a two-label stack. > | > the more scaleable way three-label pushes is not desireable due to > | > lack of debugging tools [read: MPLS PING], which two-label > | > approaches cleary have; > | > > | > so my client decided to redistribute the few hundred remote-AS PEs > | > into IS-IS, which does not do that much harm as the reflect in a > | > certain sense "infrastructure" routes; > | > | you don't need 8 bytes for this. > > stefano, > > i am not telling that using 32-bit IDs this is not possible, all i am > telling is that tags already assigned via an extended community are > _convenient_; > > policy drafts like your one are all about _convenience_ > e.g. route-leaking is done just fine for a couple of years based on > access lists - however these are cumbersone to maintain and ultimately > you guys have come up with a _convenient_ ways of controlling route > leakage -> i.e. tags; > > in multiprovider VPN setups routes are already tagged by extd. > communities; > > if i want to get routes across my transit-AS i need > to setup two policies at the ASBR for each target; > > 1. extd.community->32-bit route-tag and restore it at > the second border router > > 2. 32-bit route-tag->extd.community in order to > enable "normal" filters based on BGP communities; > > pls note that this procedure need to be done for _every_ route-target; > > --- > > howver for 64-bit tags the AS_wide policy is simple. > > 1. at the first ASBR translate all extd.communities to > 64-bit tags and > 2. translate the 64-bit tags back to communities; > > the adv. is here that i need to setup just one policy > through my AS which stays in place forever; - some sort > of implicit wildcarding; > > in the 32-bit case i need to setup translation policies > on _all_ the ASBRs fore _every_ route-target, > which does not scale administratively; > > --- > > what are you concerned about ? storage space in LSPs ? > > i guess its fair here to trade some scalability of the protocol > against convencience. > > > /hannes > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 18:48:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08585 for ; Tue, 2 Apr 2002 18:47:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32Mv8t63588; Tue, 2 Apr 2002 14:57:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32MoEt63492 for ; Tue, 2 Apr 2002 14:50:14 -0800 (PST) (envelope-from fenner@research.att.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g32N1Jn79595 for ; Tue, 2 Apr 2002 15:01:19 -0800 (PST) X-JNPR-Received-From: outside Received: from stash.attlabs.att.com ([12.106.35.2]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 2 Apr 2002 14:58:36 -0800 Received: from stash.attlabs.att.com (localhost [127.0.0.1]) by stash.attlabs.att.com (8.12.2/8.12.2) with ESMTP id g32Mo9I2044819; Tue, 2 Apr 2002 14:50:09 -0800 (PST) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.2/8.12.2/Submit) id g32Mo757044817; Tue, 2 Apr 2002 14:50:07 -0800 (PST) Message-Id: <200204022250.g32Mo757044817@stash.attlabs.att.com> To: routing-discussion@ietf.org From: Bill Fenner X-OriginalArrivalTime: 02 Apr 2002 22:58:37.0015 (UTC) FILETIME=[EC2A9670:01C1DA99] Subject: [Isis-wg] routing-discussion mailing list resurrected Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 14:50:07 -0800 (PST) Dear Routing Area participants, Alex and I have resurrected the routing-discussion mailing list, routing-discussion@ietf.org (routing-discussion-request@ietf.org to subscribe, or https://www1.ietf.org/mailman/listinfo/routing-discussion). This list is intended for use for general routing area issues, especially routing-related items that cross multiple working groups or do not fall specifically within a given group's charter. It will also be used for cross-area coordination of routing issues. Please sign up for the list if you are interested. Thanks, Bill and Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 2 18:48:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08597 for ; Tue, 2 Apr 2002 18:48:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32Ms0t63535; Tue, 2 Apr 2002 14:54:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gateway.ipinfusion.com (gt.ipinfusion.com [209.11.132.18] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g32Mrht63523 for ; Tue, 2 Apr 2002 14:53:43 -0800 (PST) (envelope-from shuqin@ipinfusion.com) Received: from ipinfusion.com (IDENT:shukin@[10.10.0.21]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g32N2kH14496 for ; Tue, 2 Apr 2002 15:02:46 -0800 Message-ID: <3CAA1A52.A5396F3F@ipinfusion.com> From: shuqin Organization: IP Infusion Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g32Mrht63524 Subject: [Isis-wg] LSP checksum generation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 02 Apr 2002 14:53:38 -0600 Content-Transfer-Encoding: 8bit Hi, I have several questions about using the checksum algorithms specified in ISO-8473, Annex C: In ISIS, the checksum calculation shall start with LSPID field to the end of packet. 1. Is it correct to set n=12 (the position of the first octet of the checksum parameter), L= pdu_length - 12 (excluding common header, PDU Length field and Remaining Lifetime field); 2. To calculate X and Y, I use the following formula derived from C.3 C0 = 0; C1 = 0; checksum = 0; for (i = 0; i < L; i++) { C0 +=SP[i]; C1 += C0; } X = ((L - n) * C0 - C1) % 255; Y = ((L - n + 1) * (-C0) + C1) % 255; if (X <= 0) X += 255; if (Y <=0) Y += 255; 3. To calculate checksum, checksum = htons( X << 8 + Y); 4. Then I use the algorithm specified in C.4 to check the generated checksum after I put this checksum value into the lsp header, each time checksum fails. Can anybody tell me what is wrong with the above calculation or parameter setting? How I can get the result correctly calculated? Here is a sample of LSP pkt for checksum calculation starting from field LSPID, the checksum field is in the 12th, which is ed52 after calculation. 00 b0 d0 da 92 37 01 00 00 00 00 31 ed 52 03 81 01 cc 84 04 0a 0a 0c 15 02 17 00 0a 80 80 80 00 b0 d0 da 0040 92 37 00 0a 80 80 80 00 00 00 00 00 01 00 Thanks in advance. - Shuqin _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 3 15:23:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14627 for ; Wed, 3 Apr 2002 15:23:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g33K65t69154; Wed, 3 Apr 2002 12:06:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g33K5bt69142 for ; Wed, 3 Apr 2002 12:05:37 -0800 (PST) (envelope-from cast@allegronetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g33KGm629604 for ; Wed, 3 Apr 2002 12:16:48 -0800 (PST) X-JNPR-Received-From: outside Received: from tahoe.allegronetworks.com ([63.115.58.10]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Apr 2002 12:01:46 -0800 Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:01:54 -0800 Message-ID: From: Neal Castagnoli To: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Apr 2002 20:01:46.0187 (UTC) FILETIME=[620879B0:01C1DB4A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Apr 2002 12:01:53 -0800 > -----Original Message----- > From: Tony Przygienda [mailto:prz@net4u.ch] > And last juicy morcel: 1195 and OSPF want you to set > aggregate metric to max. metric of aggregated prefixes. 1195 instructs you to configure the aggregate metric. This is accomplished by manual configuration of summary addresses. Each level 2 router may be configured with one or more [IP address, subnet mask, metric] entries for announcement in their level 2 LSPs. --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 4 06:06:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09562 for ; Thu, 4 Apr 2002 06:06:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34Aqht73377; Thu, 4 Apr 2002 02:52:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34AnVt73354 for ; Thu, 4 Apr 2002 02:49:31 -0800 (PST) (envelope-from ramanann@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g34B0kn15856 for ; Thu, 4 Apr 2002 03:00:46 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 02:57:48 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 04 Apr 2002 16:48:00 +0530 Received: from ramanann (ramanann.future.futsoft.com [10.20.6.44]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g34Awsv03317 for ; Thu, 4 Apr 2002 16:28:54 +0530 Reply-To: From: "Ramanan" To: "Isis-Wg (E-mail)" Message-Id: <000001c1dbc8$ca5e3bc0$2c06140a@ramanann.future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2002 10:57:48.0749 (UTC) FILETIME=[8F0467D0:01C1DBC7] Subject: [Isis-wg] draft-ietf-isis-wg-mib-07 - Validation ?? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 4 Apr 2002 16:36:36 +0530 Content-Transfer-Encoding: 7bit Hi When validating the "draft-ietf-isis-wg-mib-07.txt" in the following link, http://snmp.cs.utwente.nl/ietf/mibs/validate/ the following errors are obtained. 1. identifier `InetAddressPrefixLength' cannot be imported from module `INET-ADDRESS-MIB' 2. index element `isisAreaAddr' of row `isisAreaAddrEntry' should be not-accessible in SMIv2 MIB 3. index element `isisISAdjAreaAddress' of row `isisISAdjAreaAddrEntry' should be not-accessible in SMIv2 MIB 4. index element `isisISAdjProtSuppProtocol' of row `isisISAdjProtSuppEntry' should be not-accessible in SMIv2 MIB I believe InetAddressPrefixLength is not defined in "INET-ADDRESS-MIB" Correct me if I am wrong Regards Ramanan *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 4 07:37:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11613 for ; Thu, 4 Apr 2002 07:37:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34CNPt74301; Thu, 4 Apr 2002 04:23:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34CCpt74247 for ; Thu, 4 Apr 2002 04:12:52 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g34CO6642564 for ; Thu, 4 Apr 2002 04:24:07 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 04:00:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10773; Thu, 4 Apr 2002 07:02:34 -0500 (EST) Message-Id: <200204041202.HAA10773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 04 Apr 2002 12:00:57.0078 (UTC) FILETIME=[61098960:01C1DBD0] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 04 Apr 2002 07:02:34 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-03.txt Pages : 5 Date : 03-Apr-02 This draft describes an optional extension to IS-IS protocol, used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally does not provide CSNP and PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-snp-checksum-03.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-snp-checksum-03.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: <20020403141207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020403141207.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 4 10:15:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18157 for ; Thu, 4 Apr 2002 10:15:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34F10t75025; Thu, 4 Apr 2002 07:01:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g34F0dt75013 for ; Thu, 4 Apr 2002 07:00:39 -0800 (PST) (envelope-from jparker@axiowave.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g34FBs645216 for ; Thu, 4 Apr 2002 07:11:54 -0800 (PST) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 07:06:46 -0800 Message-ID: From: Jeff Parker To: "'ramanann@future.futsoft.com'" , "Isis-Wg (E-mail)" Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-07 - Validation ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Apr 2002 15:06:46.0889 (UTC) FILETIME=[56D7AD90:01C1DBEA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 4 Apr 2002 10:08:10 -0500 > Hi > When validating the "draft-ietf-isis-wg-mib-07.txt" in the > following link, > http://snmp.cs.utwente.nl/ietf/mibs/validate/ > > the following errors are obtained. > > 1. identifier `InetAddressPrefixLength' cannot be imported from module > `INET-ADDRESS-MIB' %InetAddressPrefixLength rfc2851.txt and a third one whose syntax is InetAddressPrefixLength. The InetAddress value while the InetAddressPrefixLength identifies the InetAddressPrefixLength, InetPortNumber, InetAddressPrefixLength ::= TEXTUAL-CONVENTION ... > 2. index element `iseaAddr' of row `isisAreaAddrEntry' should be > not-accessible in SMIv2 MIB > 3. index element `isisISAdjAreaAddress' of row > `isisISAdjAreaAddrEntry' > should be not-accessible in SMIv2 MIB > 4. index element `isisISAdjProtSuppProtocol' of row > `isisISAdjProtSuppEntry' > should be not-accessible in SMIv2 MIB I have those three indicies as not-accessible in my version. > I believe InetAddressPrefixLength is not defined in > "INET-ADDRESS-MIB" > > Correct me if I am wrong > > Regards > > Ramanan > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 5 01:03:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20183 for ; Fri, 5 Apr 2002 01:03:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g355mht79135; Thu, 4 Apr 2002 21:48:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g355jUt79115 for ; Thu, 4 Apr 2002 21:45:30 -0800 (PST) (envelope-from ramanann@future.futsoft.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g355uon37042 for ; Thu, 4 Apr 2002 21:56:50 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 21:52:52 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 05 Apr 2002 11:17:52 +0530 Received: from ramanann (ramanann.future.futsoft.com [10.20.6.44]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g355Pev23717; Fri, 5 Apr 2002 10:55:40 +0530 Reply-To: From: "Ramanan" To: "'Jeff Parker'" , "'Isis-Wg (E-mail)'" Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-07 - Validation ?? Message-Id: <000f01c1dc63$5c2e5d60$2c06140a@ramanann.future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2002 05:52:53.0296 (UTC) FILETIME=[207D9300:01C1DC66] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 5 Apr 2002 11:03:03 +0530 Content-Transfer-Encoding: 7bit -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Thursday, 04 April, 2002 08:38 PM To: 'ramanann@future.futsoft.com'; Isis-Wg (E-mail) Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-07 - Validation ?? > Hi > When validating the "draft-ietf-isis-wg-mib-07.txt" in the > following link, > http://snmp.cs.utwente.nl/ietf/mibs/validate/ > > the following errors are obtained. > > 1. identifier `InetAddressPrefixLength' cannot be imported from module > `INET-ADDRESS-MIB' %InetAddressPrefixLength rfc2851.txt and a third one whose syntax is InetAddressPrefixLength. The InetAddress value while the InetAddressPrefixLength identifies the InetAddressPrefixLength, InetPortNumber, InetAddressPrefixLength ::= TEXTUAL-CONVENTION ... Ramanan>> I could not find InetAddressPrefixLength in rfc2851.txt Can you please detail me from where had you quoted the following from? "InetAddressPrefixLength ::= TEXTUAL-CONVENTION" > 2. index element `iseaAddr' of row `isisAreaAddrEntry' should be > not-accessible in SMIv2 MIB > 3. index element `isisISAdjAreaAddress' of row > `isisISAdjAreaAddrEntry' > should be not-accessible in SMIv2 MIB > 4. index element `isisISAdjProtSuppProtocol' of row > `isisISAdjProtSuppEntry' > should be not-accessible in SMIv2 MIB I have those three indices as not-accessible in my version. Ramanan>> Mib present in the following link http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt has the elements as READ-ONLY isisAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current isisISAdjAreaAddress OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only Can you please send me your version of the mib? If these elements are not accessible, then how to access those tables as these do not have any other object other than the indices? This is very well like not having those tables at all... *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 5 09:34:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05877 for ; Fri, 5 Apr 2002 09:34:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g35EIPt82187; Fri, 5 Apr 2002 06:18:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g35EBet82138 for ; Fri, 5 Apr 2002 06:11:40 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id QAA04395; Fri, 5 Apr 2002 16:22:29 +0200 From: Hannes Gredler To: "Martin, Christian" Cc: "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 Message-ID: <20020405162229.A4232@juniper.net> References: <94B9091E1149D411A45C00508BACEB35015F2D18@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <94B9091E1149D411A45C00508BACEB35015F2D18@entmail.gnilink.com>; from cmartin@gnilink.net on Tue, Apr 02, 2002 at 12:47:20PM -0500 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 5 Apr 2002 16:22:29 +0200 tx martin for the heads-up; a customer of mine ran into the following: inter-AS MPLS VPN, AS2 is the transit AS, connected by two BGP border routers each [ASBR12, ASBR21, ASBR22 & ASBR31] AS2(IS-IS) / \ AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 problem: most of the routers in AS1,2,3 do not run labeled-BGP, and won't run for a while due to various reasons; -so there is only the IGP left for delivering the /32s of all the satellite AS border routers; idea: 1. leak all VPN PE routers /32 from AS3 into BGP-labeled-unicast between ASBR22 and ASBR31 and tag with a extd. community 2. ASBR22 redistributes (yes i know BGP IGP distribution is not a good idea but these are typically not more than 100s of routes) into AS2 IS-IS cloud and "conserves" the extd. community as 64-bit tag into IS-IS 3. ASBR21 extracts the 64-bit tag and translates it back into a extd. community on the BGP session between ASBR21 and ASBR12 4. ASBR12 extracts the community and translates it back into IS-IS --- all the above can be done using 32-bit tags i know - however it gets complicated as the redistribution policy needs to get constantly updated [tag allocation etc.] everytime a new AS is added to the transit cloud [read: ISP aquisitions]; extd.comm->64-bit tag translation policies are very easy to maintain [configure & forget] and would retain lots of information where the route came from; sure it eats up LSP space however i'd like to ask the WG to think about the scalability vs. convencience aspect of large tag fields. /hannes On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: | Taking it to the WG... | | To clarify me earlier post wrt to adding additional information. When we | originally wrote the draft, we were considering adding 64 byte ACSII | remarks. Were we all able to have our cake and eat it too, this would be a | good thing. Tony Li was concerned that adding too much information would | result in wasted LSP space and faster LSP-space exhaustion (with the | corresponding scale-reduction effect). | | Hannes, can you clarify the scenario you are presenting? From a 2547bis | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC | environment is required. | | Thx, | chris | | | | | -----Original Message----- | From: stefano previdi [mailto:sprevidi@cisco.com] | Sent: Tuesday, April 02, 2002 8:16 AM | To: Hannes Gredler | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 | | | | personally, I have no problems with 64 bits. I just think it's not a | good idea to make a generic rule just because one particular specific | case (that can be solved with 32bits anyway). | | If the WG is fine with it, I'm fine too. | | So, please send your comments to the group. | | s. | | | | On Monday 01 April 2002 22:33, Hannes Gredler wrote: | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: | > | > | > Hannes, | > | > | > | > | > | > Danny McPherson suggested this some time back. We chose to | > | > | > stay at 32 bits to be comparable to OSPF tags, but the | > | > | > addition of a 64 bit tag makes sense. | > | > | | > | > | it's the redistribution of BGP routes into isis that doesn't | > | > | make | > | > | a lot of sense to me. | > | > | > | > stefano, | > | > | > | > in native v4 routing i'd agree 100%- however there are | > | > interprovider CoC scenarios where redistributing remote-AS PE | > | > routers into ISIS/LDP is the only way to get a two-label stack. | > | > the more scaleable way three-label pushes is not desireable due to | > | > lack of debugging tools [read: MPLS PING], which two-label | > | > approaches cleary have; | > | > | > | > so my client decided to redistribute the few hundred remote-AS PEs | > | > into IS-IS, which does not do that much harm as the reflect in a | > | > certain sense "infrastructure" routes; | > | | > | you don't need 8 bytes for this. | > | > stefano, | > | > i am not telling that using 32-bit IDs this is not possible, all i am | > telling is that tags already assigned via an extended community are | > _convenient_; | > | > policy drafts like your one are all about _convenience_ | > e.g. route-leaking is done just fine for a couple of years based on | > access lists - however these are cumbersone to maintain and ultimately | > you guys have come up with a _convenient_ ways of controlling route | > leakage -> i.e. tags; | > | > in multiprovider VPN setups routes are already tagged by extd. | > communities; | > | > if i want to get routes across my transit-AS i need | > to setup two policies at the ASBR for each target; | > | > 1. extd.community->32-bit route-tag and restore it at | > the second border router | > | > 2. 32-bit route-tag->extd.community in order to | > enable "normal" filters based on BGP communities; | > | > pls note that this procedure need to be done for _every_ route-target; | > | > --- | > | > howver for 64-bit tags the AS_wide policy is simple. | > | > 1. at the first ASBR translate all extd.communities to | > 64-bit tags and | > 2. translate the 64-bit tags back to communities; | > | > the adv. is here that i need to setup just one policy | > through my AS which stays in place forever; - some sort | > of implicit wildcarding; | > | > in the 32-bit case i need to setup translation policies | > on _all_ the ASBRs fore _every_ route-target, | > which does not scale administratively; | > | > --- | > | > what are you concerned about ? storage space in LSPs ? | > | > i guess its fair here to trade some scalability of the protocol | > against convencience. | > | > | > /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 5 10:25:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07320 for ; Fri, 5 Apr 2002 10:25:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g35F9ot82457; Fri, 5 Apr 2002 07:09:50 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g35Enft82358 for ; Fri, 5 Apr 2002 06:49:41 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-07 - Validation ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 5 Apr 2002 10:00:51 -0500 > I could not find InetAddressPrefixLength in rfc2851.txt > Can you please detail me from where had you quoted the following from? > "InetAddressPrefixLength ::= TEXTUAL-CONVENTION" I'm sorry: I was too hasty with the cut and paste. RFC 2851 has been updated, and MIB authors are being encouraged to use the conventions described in http://search.ietf.org/internet-drafts/draft-ietf-ops-rfc2851-update-06.txt - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 05:49:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18695 for ; Mon, 8 Apr 2002 05:49:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g389Z1t02747; Mon, 8 Apr 2002 02:35:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g389YZt02732 for ; Mon, 8 Apr 2002 02:34:35 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4267.cisco.com [10.50.16.170]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29606; Mon, 8 Apr 2002 10:46:11 +0100 (BST) Message-Id: <4.3.2.7.2.20020408104318.04261008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: nabendu das From: mike shand Subject: Re: [Isis-wg] confusion about minLSPTransmissionInterval Cc: isis-wg@spider.juniper.net In-Reply-To: <20020402081254.31168.qmail@web13203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 08 Apr 2002 10:46:08 +0100 Originally LSP transmission throttling was only defined for LAN circuits, but most implementation now provide it for pt-pt circuits as well. The throttling is to do with the total LSP transmission rate of all LSPs (new or re-transmissions) over a particular circuit. minLSPtransInt is to do with the re-transmission rate of a particular LSP. Mike At 00:12 02/04/2002 -0800, nabendu das wrote: >hi list, >confusion about minLSPTransmissionInterval. >in ISO-10589 7.3.14.3 , >"The Update Process scans the Link State Database for >Link Stat PDUs with SRMflags set. when one is found, >provided the timestamp lastSent indicates that it was >propagated no more recently than >minimumLSPTransmissionInterval, the IS shall >a) transmit it on all circuits with SRMflags set, and >b) update lastSent." >now here it is not being told whether above mentioned >check is for P2P link or Broadcast link, Do we need to >check this for p2p as well as for LAN case???? or >minimumBroadcastLSPTransmissionInterval takes care of >that, and if so " how does >minimumBroadcastLSPTransmissionInterval controls how >fast we send back-to-back LSPs as per the new >MIB(isisCircLevelLSPThrottle)???? is it like the way >as stated in ISO 10589 in 7.3.15.6, as "as IS is >permitted to transmit a small no of LSPs with a >shorter seperation interval, provided that no more >than 1000/minimumLSPTransmissionInterval LSPs are >transmitted in any one second period."???????? > >and again in 7.3.15.5, >" an IS shall perform the folln every >minimumLSPTransmissionInterval - >for all p2p circuits c transmit all LSPs that have >SRMflags set on circuit C." > and below that >" the interval between two consecutive transmission of >the same LSP shall be at least >minimumLSPTransmissionInterval" >the question is if the IS shall perform the action as >stated in 7.3.15.5 for every >minimumLSPTransmissionInterval, then the interval >between two consecutive transmission of the same LSP >will be at least minimumLSPTransmissionInterval >anyway. so why that has again been stated.??? > >Plz help. >thanking in advance. > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://http://taxes.yahoo.com/ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 11:59:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28028 for ; Mon, 8 Apr 2002 11:59:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Fk0t05092; Mon, 8 Apr 2002 08:46:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Fj6t05080 for ; Mon, 8 Apr 2002 08:45:06 -0700 (PDT) (envelope-from corwyn@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-40-164.lucent.com [152.148.40.164]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g38Fuja29837 for ; Mon, 8 Apr 2002 11:56:46 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2650.21) id <1QG2F9YS>; Mon, 8 Apr 2002 11:56:45 -0400 Message-ID: From: "Miyagishima, Corwyn (Corwyn)" To: "'isis-wg@spider.juniper.net'" Cc: "Sciandra, Francesco (Francesco)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] IS-IS Restart Capability: receiving/processing "old" IIH packets? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 8 Apr 2002 11:56:45 -0400 I guess it's time for me to delurk... It seems as though there's a decently high (or at least non-zero) probability that Restart Capability can fail under normal operating circumstances, if I'm reading the draft properly. Please forgive me if this has been discussed before (I didn't see it in the archives) or if I'm misunderstanding something... Given that a restarting router ("A") is probably in an unstable state for some length of time, it might not be immediately able to process the packets it receives, so a periodic IIH might be sent by a neighbor ("B") before A has signalled a restart, but not processed until after A has sent an IIH with the RR bit set. As such, A will then assume that B has failed a restart and revert back to a start, rather than a restart. Is this a correct analysis? If, indeed, this is a side-effect of the current design, would it be prudent to allow A to "ignore" a certain number (1? 3? 42?) of IIHs without the RA bit set immediately following a restart, or is there a better solution to this? Thanks! Corwyn Y. Miyagishima Senior Software Engineer Lucent Technologies 978-952-7632 _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 12:42:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29473 for ; Mon, 8 Apr 2002 12:42:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38GSgt05333; Mon, 8 Apr 2002 09:28:42 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38GPIt05313 for ; Mon, 8 Apr 2002 09:25:18 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp182.cisco.com [10.50.0.181]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA14153; Mon, 8 Apr 2002 17:36:56 +0100 (BST) Message-Id: <4.3.2.7.2.20020408172410.04277008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Miyagishima, Corwyn (Corwyn)" From: mike shand Subject: Re: [Isis-wg] IS-IS Restart Capability: receiving/processing "old" IIH packets? Cc: "'isis-wg@spider.juniper.net'" , "Sciandra, Francesco (Francesco)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 08 Apr 2002 17:36:49 +0100 At 11:56 08/04/2002 -0400, Miyagishima, Corwyn (Corwyn) wrote: >I guess it's time for me to delurk... > >It seems as though there's a decently high (or at least non-zero) >probability that Restart Capability can fail under normal operating >circumstances, if I'm reading the draft properly. Please forgive me if this >has been discussed before (I didn't see it in the archives) or if I'm >misunderstanding something... > >Given that a restarting router ("A") is probably in an unstable state for >some length of time, it might not be immediately able to process the packets >it receives, so a periodic IIH might be sent by a neighbor ("B") before A >has signalled a restart, but not processed until after A has sent an IIH >with the RR bit set. As such, A will then assume that B has failed a >restart and revert back to a start, rather than a restart. Is this a >correct analysis? No. The text below from the draft describes the case where the IIH contains NO restart option. Receipt of an IIH not containing the "re-start" option is also treated as an acknowledgement, since it indicates that the neighbor is not re-start capable. In this case the neighbor will have re-initialized the adjacency as normal, which in the case of a Point-to-Point link will guarantee that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. In the case of a LAN interface, the usual operation of the update process will also ensure that synchronization is eventually achieved. However, since no CSNP is guaranteed to be received over this interface, T1 is cancelled immediately without waiting for a CSNP. Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.3). However, in the case you describe, the IIH will still contain the restart option (because the neighbor is re-start capable,) but it will NOT have the RA bit set. In this case it will simply be ignored and eventually the IIH with the RA bit set will be received (or if not, the RR will be retransmitted). Mike >If, indeed, this is a side-effect of the current design, would it be prudent >to allow A to "ignore" a certain number (1? 3? 42?) of IIHs without the RA >bit set immediately following a restart, or is there a better solution to >this? >Thanks! > >Corwyn Y. Miyagishima >Senior Software Engineer >Lucent Technologies >978-952-7632 > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 12:52:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29656 for ; Mon, 8 Apr 2002 12:52:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Gdet05460; Mon, 8 Apr 2002 09:39:40 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38GU0t05355 for ; Mon, 8 Apr 2002 09:30:01 -0700 (PDT) (envelope-from corwyn@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-40-164.lucent.com [152.148.40.164]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g38Gffp23700 for ; Mon, 8 Apr 2002 12:41:41 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2650.21) id <1QG2F099>; Mon, 8 Apr 2002 12:41:40 -0400 Message-ID: From: "Miyagishima, Corwyn (Corwyn)" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" , "Sciandra, Francesco (Francesco)" Subject: RE: [Isis-wg] IS-IS Restart Capability: receiving/processing "old " IIH packets? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 8 Apr 2002 12:41:38 -0400 Ok, I think I was confusing "not containing the 're-start' option" with not responding with the RA bit, and you just confirmed for me that we should ignore the IIH(s) received without the RA bit set, so that takes care of my question. Thank you very much! Corwyn Y. Miyagishima Senior Software Engineer Lucent Technologies 978-952-7632 > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Monday, April 08, 2002 12:37 PM > To: Miyagishima, Corwyn (Corwyn) > Cc: 'isis-wg@spider.juniper.net'; Sciandra, Francesco (Francesco) > Subject: Re: [Isis-wg] IS-IS Restart Capability: receiving/processing > "old" IIH packets? > > > At 11:56 08/04/2002 -0400, Miyagishima, Corwyn (Corwyn) wrote: > > >I guess it's time for me to delurk... > > > >It seems as though there's a decently high (or at least non-zero) > >probability that Restart Capability can fail under normal operating > >circumstances, if I'm reading the draft properly. Please > forgive me if this > >has been discussed before (I didn't see it in the archives) or if I'm > >misunderstanding something... > > > >Given that a restarting router ("A") is probably in an > unstable state for > >some length of time, it might not be immediately able to > process the packets > >it receives, so a periodic IIH might be sent by a neighbor > ("B") before A > >has signalled a restart, but not processed until after A has > sent an IIH > >with the RR bit set. As such, A will then assume that B has failed a > >restart and revert back to a start, rather than a restart. Is this a > >correct analysis? > > No. The text below from the draft describes the case where > the IIH contains > NO restart option. > > Receipt of an IIH not containing the "re-start" option is > also treated as > an acknowledgement, since it indicates that the neighbor is > not re-start > capable. In this case the neighbor will have re-initialized > the adjacency > as normal, which in the case of a Point-to-Point link will > guarantee that > SRMflags have been set on its database, thus ensuring eventual LSPDB > synchronization. In the case of a LAN interface, the usual > operation of the > update process will also ensure that synchronization is eventually > achieved. However, since no CSNP is guaranteed to be received > over this > interface, T1 is cancelled immediately without waiting for a CSNP. > Synchronization may therefore be deemed complete even though > there are some > LSPs which are held (only) by this neighbor (see section 4.3). > > However, in the case you describe, the IIH will still contain > the restart > option (because the neighbor is re-start capable,) but it > will NOT have the > RA bit set. In this case it will simply be ignored and > eventually the IIH > with the RA bit set will be received (or if not, the RR will > be retransmitted). > > Mike > > > >If, indeed, this is a side-effect of the current design, > would it be prudent > >to allow A to "ignore" a certain number (1? 3? 42?) of > IIHs without the RA > >bit set immediately following a restart, or is there a > better solution to > >this? > > > > > > >Thanks! > > > >Corwyn Y. Miyagishima > >Senior Software Engineer > >Lucent Technologies > >978-952-7632 > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 14:58:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02795 for ; Mon, 8 Apr 2002 14:58:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Ihht06133; Mon, 8 Apr 2002 11:43:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Id5t06102 for ; Mon, 8 Apr 2002 11:39:05 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Hello Multiplier - FINAL ROUND Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 8 Apr 2002 14:50:30 -0400 While there is still discussion on some of the topics, I hope we can close out a few of the more straight forward ones such as Hello Multiplier. If there is debate about this or other "Final" rounds, we will keep them open until rough consensus emerges. I will circulate the current versions of all items, together with a note about what has changed, and a list of any questions open in my mind. - jeff parker - Included historical note about original value in DECnet 5.2 Hello Multiplier An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic basis over active circuits, allowing other attached routers to moni- tor their aliveness. The IIH includes a two byte field called the Holding Time which defines the time to live of an adjacency. If an IS does not receive a hello from an adjacent IS within this holding time, the adjacent IS is assumed to be no longer operational, and the adjacency is removed. [ten] states that the value of Holding Time should be ISISHolding- Multiplier multiplied by iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS, and sets ISISHoldingMultiplier to a value of 10. This implies that the neighbor must lose 10 IIHs before an adjacency times out. In practice, a value of 10 for the ISISHoldingMultiplier has proven to be too large. Most implementations set the default ISISHoldingMul- tiplier to 3, the original value in DECnet PhaseV, and allow the net- work operator to configure it. Note that the Holding Timer may be asymmetric among the routers on the same link. Thus Hello Multiplier may be a configurable administrative parameter, with values between 3 and 10. Values lower than 3 are less stable, and may cause adjacencies to flap. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 15:16:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03408 for ; Mon, 8 Apr 2002 15:16:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38J37t06256; Mon, 8 Apr 2002 12:03:07 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Ifnt06118 for ; Mon, 8 Apr 2002 11:41:49 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Sys-ID Length - FINAL Round Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 8 Apr 2002 14:53:24 -0400 - Motivation for length of 6 - Note that some TLVs assumer length of 6 - The range (1..8) is not discussed. I'm happy to, but don't see the point. - jdp 6.0 Variables Which Are Constant Some parameters to the protocol were defined as variable, but rarely vary in practice. These include (1) System-ID Length (2) Maximum Area Addresses 6.1 System-ID Length The System ID is allowed to be as long as 8 bytes. Since it was easy to use an Ethernet MAC address to generate a unique 6 byte System ID, and since the SystemID only has significance within the IGP Domain, 6 bytes has proved to be ample and is widely used. Moreover, new IS-IS TLVs such as the Traffic Engineering TLVs, are assuming a 6 byte Sys- tem ID, so choices other than 6 are difficult to support. Implementations may interoperate without being able to deal with Sys- tem IDs of any length other than 6. Of course implementation must check the ID Length defined in the IS-IS PDUs it receives, and dis- card PDUs that do not match the local value. But a System ID of length 6 is so widely used that this is the only value an implementa- tion needs to support. - jeff parker - axiowave networks - Times are bad. Children no longer obey their parents, and everyone is writing a book - Cicero (106-43 BCE) _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 16:45:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05829 for ; Mon, 8 Apr 2002 16:45:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38KVot06715; Mon, 8 Apr 2002 13:31:50 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38K7Ct06603 for ; Mon, 8 Apr 2002 13:07:12 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g38KIidQ025320; Mon, 8 Apr 2002 16:18:44 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-441.cisco.com [10.82.241.185]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABD76709; Mon, 8 Apr 2002 16:18:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20020408160121.038eec28@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: Re: [Isis-wg] Hello Multiplier - FINAL ROUND Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 08 Apr 2002 16:04:04 -0400 Trivial edit suggestion below. Keep or toss, no reply necessary. At 02:50 PM 4/8/2002, Jeff Parker wrote: >While there is still discussion on some of the topics, I hope >we can close out a few of the more straight forward ones >such as Hello Multiplier. If there is debate about this >or other "Final" rounds, we will keep them open until >rough consensus emerges. > >I will circulate the current versions of all items, together >with a note about what has changed, and a list of any questions >open in my mind. > >- jeff parker > > >- Included historical note about original value in DECnet > > >5.2 Hello Multiplier > > An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic > basis over active circuits, allowing other attached routers to moni- > tor their aliveness. The IIH includes a two byte field called the > Holding Time which defines the time to live of an adjacency. If an IS > does not receive a hello from an adjacent IS within this holding > time, the adjacent IS is assumed to be no longer operational, and the > adjacency is removed. > > [ten] states that the value of Holding Time should be ISISHolding- > Multiplier multiplied by iSISHelloTimer for ordinary systems, and > dRISISHelloTimer for a DIS, and sets ISISHoldingMultiplier to a value > of 10. This implies that the neighbor must lose 10 IIHs before an > adjacency times out. > > In practice, a value of 10 for the ISISHoldingMultiplier has proven > to be too large. Most implementations set the default ISISHoldingMul- > tiplier to 3, the original value in DECnet PhaseV, and allow the net- > work operator to configure it. Note that the Holding Timer may be > asymmetric among the routers on the same link. ... the Holding Timer need not be set consistently among the routers ... > Thus Hello Multiplier may be a configurable administrative parameter, > with values between 3 and 10. Values lower than 3 are less stable, > and may cause adjacencies to flap. >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 8 18:30:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08404 for ; Mon, 8 Apr 2002 18:30:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38MGWt07246; Mon, 8 Apr 2002 15:16:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38M1Xt07172 for ; Mon, 8 Apr 2002 15:01:33 -0700 (PDT) (envelope-from cast@allegronetworks.com) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:11:37 -0700 Message-ID: From: Neal Castagnoli To: "'Jeff Parker'" , "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Sys-ID Length - FINAL Round MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 8 Apr 2002 15:11:29 -0700 I think that 0 is also a valid value for systemID, and is equivalent to six, similar to the 0/3 maximum area addresses. --Neal > - Motivation for length of 6 > - Note that some TLVs assumer length of 6 > > - The range (1..8) is not discussed. I'm happy to, but don't > see the point. > > > - jdp > > 6.0 Variables Which Are Constant > > Some parameters to the protocol were defined as variable, > but rarely > vary in practice. These include > > (1) System-ID Length > > (2) Maximum Area Addresses > > 6.1 System-ID Length > > The System ID is allowed to be as long as 8 bytes. Since > it was easy > to use an Ethernet MAC address to generate a unique 6 byte > System ID, > and since the SystemID only has significance within the > IGP Domain, 6 > bytes has proved to be ample and is widely used. Moreover, > new IS-IS > TLVs such as the Traffic Engineering TLVs, are assuming a > 6 byte Sys- > tem ID, so choices other than 6 are difficult to support. > > Implementations may interoperate without being able to > deal with Sys- > tem IDs of any length other than 6. Of course implementation must > check the ID Length defined in the IS-IS PDUs it receives, and dis- > card PDUs that do not match the local value. But a System ID of > length 6 is so widely used that this is the only value an > implementa- > tion needs to support. > > > > - jeff parker > - axiowave networks > - Times are bad. Children no longer obey their parents, and > everyone is > writing a book > - Cicero (106-43 BCE) > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 06:36:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01292 for ; Tue, 9 Apr 2002 06:36:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39AKtt10960; Tue, 9 Apr 2002 03:20:55 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g38Lsot07133 for ; Mon, 8 Apr 2002 14:54:50 -0700 (PDT) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g38M6Xn01902 for ; Mon, 8 Apr 2002 15:06:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 14:56:15 -0700 Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id A7F7626280F for ; Mon, 8 Apr 2002 14:57:59 -0700 (PDT) Message-ID: <3CB1F321.CE193FBD@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2002 21:56:15.0858 (UTC) FILETIME=[34BDD520:01C1DF48] Subject: [Isis-wg] FYI: Design team formation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 08 Apr 2002 12:44:33 -0700 Content-Transfer-Encoding: 7bit A design team has been formed initiated by Alex Zinin i) The charter of the team is to identify and possibly provide write-downs covering differences between real-world deployed implemenations and 10589, 1195 specifications of the protocol as far as they are not dealt with by existing drafts yet. This only encompasses interoperable, external behavior and not internal implemenation details. ii) Jeff Parker is the document editor and the team lead. iii) Membership is open and the group exists under http://www1.ietf.org/mailman/listinfo/isis-update Old mailing list archives will be moved to the ietf.org server soon. iv) Current subscribed group members are: azinin@nexsi.com cast@allegronetworks.com christi@nortelnetworks.com danny@tcb.net fenner@research.att.com ginsberg@pluris.com jlearman@cisco.com jparker@axiowave.com mbartell@cisco.com mshand@cisco.com prz@redback.com riw@cisco.com satish@pluris.com sprevidi@cisco.com SVEMULAP@cisco.com tli@procket.com vishwasm@netplane.com v) In case of extended lifetime of the design team, a short report on the issues/status will be forwarded to the ISIS mailing list every 3 months. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 07:02:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01729 for ; Tue, 9 Apr 2002 07:02:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39An0t11144; Tue, 9 Apr 2002 03:49:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miles.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39Ambt11132 for ; Tue, 9 Apr 2002 03:48:37 -0700 (PDT) (envelope-from JRB@dataconnection.com) Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2655.55) id <2JA6DWND>; Tue, 9 Apr 2002 12:00:22 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7036D693A@duke.datcon.co.uk> From: Jon Berger To: "Isis-Wg (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Questions on draft-ietf-isis-gmpls-extensions-09 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 9 Apr 2002 12:00:19 +0100 I have some questions about the Link Protection Type sub-TLV and the SRLG TLV. Link Protection Type sub-TLV (section 5.3) : Why is the length of the link protection type different between IS-IS and OSPF? It is 2 octets in IS-IS and 4 in OSPF (draft-ietf-ccamp-ospf-gmpls-extensions-05). In both protocols only the value of the first octet is specified in the respective drafts. What are these other octet(s) for? Should they just be set to zero? SRLG TLV (section 5.5) : Presumably the 7 octets of system ID and pseudonode number are for the neighbor, as per the extended IS reachability TLV. Correct? If so, it would be helpful if the text explicitly said this. Thanks Jon _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 21:27:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27202 for ; Tue, 9 Apr 2002 21:27:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1D1t14852; Tue, 9 Apr 2002 18:13:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39LTYt13919 for ; Tue, 9 Apr 2002 14:29:34 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC854BA21A; Tue, 9 Apr 2002 14:41:23 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 05 Apr 2002 16:22:29 +0200 <20020405162229.A4232@juniper.net> From: Naiming Shen Message-Id: <20020409214123.CDC854BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 14:41:23 -0700 If one is going to make it a 64-bit tag, it maybe good to make it a variable size(n x 32bits) to accommodate future "crazy" applications. ] tx martin for the heads-up; ] ] a customer of mine ran into the following: ] ] inter-AS MPLS VPN, AS2 is the transit AS, ] connected by two BGP border routers each ] [ASBR12, ASBR21, ASBR22 & ASBR31] ] ] AS2(IS-IS) ] / \ ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 ] ] problem: most of the routers in AS1,2,3 do not ] run labeled-BGP, and won't run for a while due ] to various reasons; -so there is only the IGP ] left for delivering the /32s of all the satellite AS ] border routers; ] ] idea: ] ] 1. leak all VPN PE routers /32 from AS3 into ] BGP-labeled-unicast between ASBR22 and ASBR31 ] and tag with a extd. community ] ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is ] not a good idea but these are typically not more than 100s ] of routes) into AS2 IS-IS cloud ] and "conserves" the extd. community as 64-bit tag into IS-IS ] ] 3. ASBR21 extracts the 64-bit tag and translates it back ] into a extd. community on the BGP session between ] ASBR21 and ASBR12 ] ] 4. ASBR12 extracts the community and translates it back into ] IS-IS ] ] --- ] all the above can be done using 32-bit tags i know - however ] it gets complicated as the redistribution policy needs ] to get constantly updated [tag allocation etc.] everytime a new ] AS is added to the transit cloud [read: ISP aquisitions]; ] ] extd.comm->64-bit tag translation policies are very easy to maintain ] [configure & forget] and would retain lots of information where the ] route came from; sure it eats up LSP space however ] i'd like to ask the WG to think about the scalability vs. ] convencience aspect of large tag fields. ] ] /hannes ] ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: ] | Taking it to the WG... ] | ] | To clarify me earlier post wrt to adding additional information. When we ] | originally wrote the draft, we were considering adding 64 byte ACSII ] | remarks. Were we all able to have our cake and eat it too, this would be a ] | good thing. Tony Li was concerned that adding too much information would ] | result in wasted LSP space and faster LSP-space exhaustion (with the ] | corresponding scale-reduction effect). ] | ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC ] | environment is required. ] | ] | Thx, ] | chris ] | ] | ] | ] | ] | -----Original Message----- ] | From: stefano previdi [mailto:sprevidi@cisco.com] ] | Sent: Tuesday, April 02, 2002 8:16 AM ] | To: Hannes Gredler ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 ] | ] | ] | ] | personally, I have no problems with 64 bits. I just think it's not a ] | good idea to make a generic rule just because one particular specific ] | case (that can be solved with 32bits anyway). ] | ] | If the WG is fine with it, I'm fine too. ] | ] | So, please send your comments to the group. ] | ] | s. ] | ] | ] | ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: ] | > | > | > Hannes, ] | > | > | > ] | > | > | > Danny McPherson suggested this some time back. We chose to ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the ] | > | > | > addition of a 64 bit tag makes sense. ] | > | > | ] | > | > | it's the redistribution of BGP routes into isis that doesn't ] | > | > | make ] | > | > | a lot of sense to me. ] | > | > ] | > | > stefano, ] | > | > ] | > | > in native v4 routing i'd agree 100%- however there are ] | > | > interprovider CoC scenarios where redistributing remote-AS PE ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. ] | > | > the more scaleable way three-label pushes is not desireable due to ] | > | > lack of debugging tools [read: MPLS PING], which two-label ] | > | > approaches cleary have; ] | > | > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs ] | > | > into IS-IS, which does not do that much harm as the reflect in a ] | > | > certain sense "infrastructure" routes; ] | > | ] | > | you don't need 8 bytes for this. ] | > ] | > stefano, ] | > ] | > i am not telling that using 32-bit IDs this is not possible, all i am ] | > telling is that tags already assigned via an extended community are ] | > _convenient_; ] | > ] | > policy drafts like your one are all about _convenience_ ] | > e.g. route-leaking is done just fine for a couple of years based on ] | > access lists - however these are cumbersone to maintain and ultimately ] | > you guys have come up with a _convenient_ ways of controlling route ] | > leakage -> i.e. tags; ] | > ] | > in multiprovider VPN setups routes are already tagged by extd. ] | > communities; ] | > ] | > if i want to get routes across my transit-AS i need ] | > to setup two policies at the ASBR for each target; ] | > ] | > 1. extd.community->32-bit route-tag and restore it at ] | > the second border router ] | > ] | > 2. 32-bit route-tag->extd.community in order to ] | > enable "normal" filters based on BGP communities; ] | > ] | > pls note that this procedure need to be done for _every_ route-target; ] | > ] | > --- ] | > ] | > howver for 64-bit tags the AS_wide policy is simple. ] | > ] | > 1. at the first ASBR translate all extd.communities to ] | > 64-bit tags and ] | > 2. translate the 64-bit tags back to communities; ] | > ] | > the adv. is here that i need to setup just one policy ] | > through my AS which stays in place forever; - some sort ] | > of implicit wildcarding; ] | > ] | > in the 32-bit case i need to setup translation policies ] | > on _all_ the ASBRs fore _every_ route-target, ] | > which does not scale administratively; ] | > ] | > --- ] | > ] | > what are you concerned about ? storage space in LSPs ? ] | > ] | > i guess its fair here to trade some scalability of the protocol ] | > against convencience. ] | > ] | > ] | > /hannes ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 21:33:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27310 for ; Tue, 9 Apr 2002 21:33:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1K3t14905; Tue, 9 Apr 2002 18:20:03 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A0p5t14738 for ; Tue, 9 Apr 2002 17:51:06 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-163-118.cisco.com [128.107.163.118]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id DAA12879; Wed, 10 Apr 2002 03:02:36 +0200 (MET DST) Message-Id: <200204100102.DAA12879@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Hannes Gredler Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 X-Mailer: KMail [version 1.3.1] Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" References: <20020409214123.CDC854BA21A@prattle.redback.com> In-Reply-To: <20020409214123.CDC854BA21A@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3A0p6t14739 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 03:02:32 +0200 Content-Transfer-Encoding: 8bit On Tuesday 09 April 2002 23:41, Naiming Shen wrote: > If one is going to make it a 64-bit tag, it maybe good to make it > a variable size(n x 32bits) to accommodate future "crazy" applications. after some thoughts and discussions it came out that the best way is probably to define one subTLV for 32bits tags and another subTLV for 64bits ones. s. > > ] tx martin for the heads-up; > ] > ] a customer of mine ran into the following: > ] > ] inter-AS MPLS VPN, AS2 is the transit AS, > ] connected by two BGP border routers each > ] [ASBR12, ASBR21, ASBR22 & ASBR31] > ] > ] AS2(IS-IS) > ] / \ > ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 > ] > ] problem: most of the routers in AS1,2,3 do not > ] run labeled-BGP, and won't run for a while due > ] to various reasons; -so there is only the IGP > ] left for delivering the /32s of all the satellite AS > ] border routers; > ] > ] idea: > ] > ] 1. leak all VPN PE routers /32 from AS3 into > ] BGP-labeled-unicast between ASBR22 and ASBR31 > ] and tag with a extd. community > ] > ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is > ] not a good idea but these are typically not more than 100s > ] of routes) into AS2 IS-IS cloud > ] and "conserves" the extd. community as 64-bit tag into IS-IS > ] > ] 3. ASBR21 extracts the 64-bit tag and translates it back > ] into a extd. community on the BGP session between > ] ASBR21 and ASBR12 > ] > ] 4. ASBR12 extracts the community and translates it back into > ] IS-IS > ] > ] --- > ] all the above can be done using 32-bit tags i know - however > ] it gets complicated as the redistribution policy needs > ] to get constantly updated [tag allocation etc.] everytime a new > ] AS is added to the transit cloud [read: ISP aquisitions]; > ] > ] extd.comm->64-bit tag translation policies are very easy to maintain > ] [configure & forget] and would retain lots of information where the > ] route came from; sure it eats up LSP space however > ] i'd like to ask the WG to think about the scalability vs. > ] convencience aspect of large tag fields. > ] > ] /hannes > ] > ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: > ] | Taking it to the WG... > ] | > ] | To clarify me earlier post wrt to adding additional information. When we > ] | originally wrote the draft, we were considering adding 64 byte ACSII > ] | remarks. Were we all able to have our cake and eat it too, this would be > a > ] | good thing. Tony Li was concerned that adding too much information would > ] | result in wasted LSP space and faster LSP-space exhaustion (with the > ] | corresponding scale-reduction effect). > ] | > ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis > ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC > ] | environment is required. > ] | > ] | Thx, > ] | chris > ] | > ] | > ] | > ] | > ] | -----Original Message----- > ] | From: stefano previdi [mailto:sprevidi@cisco.com] > ] | Sent: Tuesday, April 02, 2002 8:16 AM > ] | To: Hannes Gredler > ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; > ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net > ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 > ] | > ] | > ] | > ] | personally, I have no problems with 64 bits. I just think it's not a > ] | good idea to make a generic rule just because one particular specific > ] | case (that can be solved with 32bits anyway). > ] | > ] | If the WG is fine with it, I'm fine too. > ] | > ] | So, please send your comments to the group. > ] | > ] | s. > ] | > ] | > ] | > ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: > ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > ] | > | > | > Hannes, > ] | > | > | > > ] | > | > | > Danny McPherson suggested this some time back. We chose to > ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the > ] | > | > | > addition of a 64 bit tag makes sense. > ] | > | > | > ] | > | > | it's the redistribution of BGP routes into isis that doesn't > ] | > | > | make > ] | > | > | a lot of sense to me. > ] | > | > > ] | > | > stefano, > ] | > | > > ] | > | > in native v4 routing i'd agree 100%- however there are > ] | > | > interprovider CoC scenarios where redistributing remote-AS PE > ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. > ] | > | > the more scaleable way three-label pushes is not desireable due to > ] | > | > lack of debugging tools [read: MPLS PING], which two-label > ] | > | > approaches cleary have; > ] | > | > > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs > ] | > | > into IS-IS, which does not do that much harm as the reflect in a > ] | > | > certain sense "infrastructure" routes; > ] | > | > ] | > | you don't need 8 bytes for this. > ] | > > ] | > stefano, > ] | > > ] | > i am not telling that using 32-bit IDs this is not possible, all i am > ] | > telling is that tags already assigned via an extended community are > ] | > _convenient_; > ] | > > ] | > policy drafts like your one are all about _convenience_ > ] | > e.g. route-leaking is done just fine for a couple of years based on > ] | > access lists - however these are cumbersone to maintain and ultimately > ] | > you guys have come up with a _convenient_ ways of controlling route > ] | > leakage -> i.e. tags; > ] | > > ] | > in multiprovider VPN setups routes are already tagged by extd. > ] | > communities; > ] | > > ] | > if i want to get routes across my transit-AS i need > ] | > to setup two policies at the ASBR for each target; > ] | > > ] | > 1. extd.community->32-bit route-tag and restore it at > ] | > the second border router > ] | > > ] | > 2. 32-bit route-tag->extd.community in order to > ] | > enable "normal" filters based on BGP communities; > ] | > > ] | > pls note that this procedure need to be done for _every_ route-target; > ] | > > ] | > --- > ] | > > ] | > howver for 64-bit tags the AS_wide policy is simple. > ] | > > ] | > 1. at the first ASBR translate all extd.communities to > ] | > 64-bit tags and > ] | > 2. translate the 64-bit tags back to communities; > ] | > > ] | > the adv. is here that i need to setup just one policy > ] | > through my AS which stays in place forever; - some sort > ] | > of implicit wildcarding; > ] | > > ] | > in the 32-bit case i need to setup translation policies > ] | > on _all_ the ASBRs fore _every_ route-target, > ] | > which does not scale administratively; > ] | > > ] | > --- > ] | > > ] | > what are you concerned about ? storage space in LSPs ? > ] | > > ] | > i guess its fair here to trade some scalability of the protocol > ] | > against convencience. > ] | > > ] | > > ] | > /hannes > ] > ] _______________________________________________ > ] Isis-wg mailing list - Isis-wg@spider.juniper.net > ] http://spider.juniper.net/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 21:39:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28315 for ; Tue, 9 Apr 2002 21:39:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1Q0t14955; Tue, 9 Apr 2002 18:26:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39LTYt13919 for ; Tue, 9 Apr 2002 14:29:34 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC854BA21A; Tue, 9 Apr 2002 14:41:23 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 05 Apr 2002 16:22:29 +0200 <20020405162229.A4232@juniper.net> From: Naiming Shen Message-Id: <20020409214123.CDC854BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 14:41:23 -0700 If one is going to make it a 64-bit tag, it maybe good to make it a variable size(n x 32bits) to accommodate future "crazy" applications. ] tx martin for the heads-up; ] ] a customer of mine ran into the following: ] ] inter-AS MPLS VPN, AS2 is the transit AS, ] connected by two BGP border routers each ] [ASBR12, ASBR21, ASBR22 & ASBR31] ] ] AS2(IS-IS) ] / \ ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 ] ] problem: most of the routers in AS1,2,3 do not ] run labeled-BGP, and won't run for a while due ] to various reasons; -so there is only the IGP ] left for delivering the /32s of all the satellite AS ] border routers; ] ] idea: ] ] 1. leak all VPN PE routers /32 from AS3 into ] BGP-labeled-unicast between ASBR22 and ASBR31 ] and tag with a extd. community ] ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is ] not a good idea but these are typically not more than 100s ] of routes) into AS2 IS-IS cloud ] and "conserves" the extd. community as 64-bit tag into IS-IS ] ] 3. ASBR21 extracts the 64-bit tag and translates it back ] into a extd. community on the BGP session between ] ASBR21 and ASBR12 ] ] 4. ASBR12 extracts the community and translates it back into ] IS-IS ] ] --- ] all the above can be done using 32-bit tags i know - however ] it gets complicated as the redistribution policy needs ] to get constantly updated [tag allocation etc.] everytime a new ] AS is added to the transit cloud [read: ISP aquisitions]; ] ] extd.comm->64-bit tag translation policies are very easy to maintain ] [configure & forget] and would retain lots of information where the ] route came from; sure it eats up LSP space however ] i'd like to ask the WG to think about the scalability vs. ] convencience aspect of large tag fields. ] ] /hannes ] ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: ] | Taking it to the WG... ] | ] | To clarify me earlier post wrt to adding additional information. When we ] | originally wrote the draft, we were considering adding 64 byte ACSII ] | remarks. Were we all able to have our cake and eat it too, this would be a ] | good thing. Tony Li was concerned that adding too much information would ] | result in wasted LSP space and faster LSP-space exhaustion (with the ] | corresponding scale-reduction effect). ] | ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC ] | environment is required. ] | ] | Thx, ] | chris ] | ] | ] | ] | ] | -----Original Message----- ] | From: stefano previdi [mailto:sprevidi@cisco.com] ] | Sent: Tuesday, April 02, 2002 8:16 AM ] | To: Hannes Gredler ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 ] | ] | ] | ] | personally, I have no problems with 64 bits. I just think it's not a ] | good idea to make a generic rule just because one particular specific ] | case (that can be solved with 32bits anyway). ] | ] | If the WG is fine with it, I'm fine too. ] | ] | So, please send your comments to the group. ] | ] | s. ] | ] | ] | ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: ] | > | > | > Hannes, ] | > | > | > ] | > | > | > Danny McPherson suggested this some time back. We chose to ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the ] | > | > | > addition of a 64 bit tag makes sense. ] | > | > | ] | > | > | it's the redistribution of BGP routes into isis that doesn't ] | > | > | make ] | > | > | a lot of sense to me. ] | > | > ] | > | > stefano, ] | > | > ] | > | > in native v4 routing i'd agree 100%- however there are ] | > | > interprovider CoC scenarios where redistributing remote-AS PE ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. ] | > | > the more scaleable way three-label pushes is not desireable due to ] | > | > lack of debugging tools [read: MPLS PING], which two-label ] | > | > approaches cleary have; ] | > | > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs ] | > | > into IS-IS, which does not do that much harm as the reflect in a ] | > | > certain sense "infrastructure" routes; ] | > | ] | > | you don't need 8 bytes for this. ] | > ] | > stefano, ] | > ] | > i am not telling that using 32-bit IDs this is not possible, all i am ] | > telling is that tags already assigned via an extended community are ] | > _convenient_; ] | > ] | > policy drafts like your one are all about _convenience_ ] | > e.g. route-leaking is done just fine for a couple of years based on ] | > access lists - however these are cumbersone to maintain and ultimately ] | > you guys have come up with a _convenient_ ways of controlling route ] | > leakage -> i.e. tags; ] | > ] | > in multiprovider VPN setups routes are already tagged by extd. ] | > communities; ] | > ] | > if i want to get routes across my transit-AS i need ] | > to setup two policies at the ASBR for each target; ] | > ] | > 1. extd.community->32-bit route-tag and restore it at ] | > the second border router ] | > ] | > 2. 32-bit route-tag->extd.community in order to ] | > enable "normal" filters based on BGP communities; ] | > ] | > pls note that this procedure need to be done for _every_ route-target; ] | > ] | > --- ] | > ] | > howver for 64-bit tags the AS_wide policy is simple. ] | > ] | > 1. at the first ASBR translate all extd.communities to ] | > 64-bit tags and ] | > 2. translate the 64-bit tags back to communities; ] | > ] | > the adv. is here that i need to setup just one policy ] | > through my AS which stays in place forever; - some sort ] | > of implicit wildcarding; ] | > ] | > in the 32-bit case i need to setup translation policies ] | > on _all_ the ASBRs fore _every_ route-target, ] | > which does not scale administratively; ] | > ] | > --- ] | > ] | > what are you concerned about ? storage space in LSPs ? ] | > ] | > i guess its fair here to trade some scalability of the protocol ] | > against convencience. ] | > ] | > ] | > /hannes ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 21:45:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28378 for ; Tue, 9 Apr 2002 21:45:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1VKt15004; Tue, 9 Apr 2002 18:31:20 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A0p5t14738 for ; Tue, 9 Apr 2002 17:51:06 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-163-118.cisco.com [128.107.163.118]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id DAA12879; Wed, 10 Apr 2002 03:02:36 +0200 (MET DST) Message-Id: <200204100102.DAA12879@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Hannes Gredler Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 X-Mailer: KMail [version 1.3.1] Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" References: <20020409214123.CDC854BA21A@prattle.redback.com> In-Reply-To: <20020409214123.CDC854BA21A@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3A0p6t14739 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 03:02:32 +0200 Content-Transfer-Encoding: 8bit On Tuesday 09 April 2002 23:41, Naiming Shen wrote: > If one is going to make it a 64-bit tag, it maybe good to make it > a variable size(n x 32bits) to accommodate future "crazy" applications. after some thoughts and discussions it came out that the best way is probably to define one subTLV for 32bits tags and another subTLV for 64bits ones. s. > > ] tx martin for the heads-up; > ] > ] a customer of mine ran into the following: > ] > ] inter-AS MPLS VPN, AS2 is the transit AS, > ] connected by two BGP border routers each > ] [ASBR12, ASBR21, ASBR22 & ASBR31] > ] > ] AS2(IS-IS) > ] / \ > ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 > ] > ] problem: most of the routers in AS1,2,3 do not > ] run labeled-BGP, and won't run for a while due > ] to various reasons; -so there is only the IGP > ] left for delivering the /32s of all the satellite AS > ] border routers; > ] > ] idea: > ] > ] 1. leak all VPN PE routers /32 from AS3 into > ] BGP-labeled-unicast between ASBR22 and ASBR31 > ] and tag with a extd. community > ] > ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is > ] not a good idea but these are typically not more than 100s > ] of routes) into AS2 IS-IS cloud > ] and "conserves" the extd. community as 64-bit tag into IS-IS > ] > ] 3. ASBR21 extracts the 64-bit tag and translates it back > ] into a extd. community on the BGP session between > ] ASBR21 and ASBR12 > ] > ] 4. ASBR12 extracts the community and translates it back into > ] IS-IS > ] > ] --- > ] all the above can be done using 32-bit tags i know - however > ] it gets complicated as the redistribution policy needs > ] to get constantly updated [tag allocation etc.] everytime a new > ] AS is added to the transit cloud [read: ISP aquisitions]; > ] > ] extd.comm->64-bit tag translation policies are very easy to maintain > ] [configure & forget] and would retain lots of information where the > ] route came from; sure it eats up LSP space however > ] i'd like to ask the WG to think about the scalability vs. > ] convencience aspect of large tag fields. > ] > ] /hannes > ] > ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: > ] | Taking it to the WG... > ] | > ] | To clarify me earlier post wrt to adding additional information. When we > ] | originally wrote the draft, we were considering adding 64 byte ACSII > ] | remarks. Were we all able to have our cake and eat it too, this would be > a > ] | good thing. Tony Li was concerned that adding too much information would > ] | result in wasted LSP space and faster LSP-space exhaustion (with the > ] | corresponding scale-reduction effect). > ] | > ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis > ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC > ] | environment is required. > ] | > ] | Thx, > ] | chris > ] | > ] | > ] | > ] | > ] | -----Original Message----- > ] | From: stefano previdi [mailto:sprevidi@cisco.com] > ] | Sent: Tuesday, April 02, 2002 8:16 AM > ] | To: Hannes Gredler > ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; > ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net > ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 > ] | > ] | > ] | > ] | personally, I have no problems with 64 bits. I just think it's not a > ] | good idea to make a generic rule just because one particular specific > ] | case (that can be solved with 32bits anyway). > ] | > ] | If the WG is fine with it, I'm fine too. > ] | > ] | So, please send your comments to the group. > ] | > ] | s. > ] | > ] | > ] | > ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: > ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > ] | > | > | > Hannes, > ] | > | > | > > ] | > | > | > Danny McPherson suggested this some time back. We chose to > ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the > ] | > | > | > addition of a 64 bit tag makes sense. > ] | > | > | > ] | > | > | it's the redistribution of BGP routes into isis that doesn't > ] | > | > | make > ] | > | > | a lot of sense to me. > ] | > | > > ] | > | > stefano, > ] | > | > > ] | > | > in native v4 routing i'd agree 100%- however there are > ] | > | > interprovider CoC scenarios where redistributing remote-AS PE > ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. > ] | > | > the more scaleable way three-label pushes is not desireable due to > ] | > | > lack of debugging tools [read: MPLS PING], which two-label > ] | > | > approaches cleary have; > ] | > | > > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs > ] | > | > into IS-IS, which does not do that much harm as the reflect in a > ] | > | > certain sense "infrastructure" routes; > ] | > | > ] | > | you don't need 8 bytes for this. > ] | > > ] | > stefano, > ] | > > ] | > i am not telling that using 32-bit IDs this is not possible, all i am > ] | > telling is that tags already assigned via an extended community are > ] | > _convenient_; > ] | > > ] | > policy drafts like your one are all about _convenience_ > ] | > e.g. route-leaking is done just fine for a couple of years based on > ] | > access lists - however these are cumbersone to maintain and ultimately > ] | > you guys have come up with a _convenient_ ways of controlling route > ] | > leakage -> i.e. tags; > ] | > > ] | > in multiprovider VPN setups routes are already tagged by extd. > ] | > communities; > ] | > > ] | > if i want to get routes across my transit-AS i need > ] | > to setup two policies at the ASBR for each target; > ] | > > ] | > 1. extd.community->32-bit route-tag and restore it at > ] | > the second border router > ] | > > ] | > 2. 32-bit route-tag->extd.community in order to > ] | > enable "normal" filters based on BGP communities; > ] | > > ] | > pls note that this procedure need to be done for _every_ route-target; > ] | > > ] | > --- > ] | > > ] | > howver for 64-bit tags the AS_wide policy is simple. > ] | > > ] | > 1. at the first ASBR translate all extd.communities to > ] | > 64-bit tags and > ] | > 2. translate the 64-bit tags back to communities; > ] | > > ] | > the adv. is here that i need to setup just one policy > ] | > through my AS which stays in place forever; - some sort > ] | > of implicit wildcarding; > ] | > > ] | > in the 32-bit case i need to setup translation policies > ] | > on _all_ the ASBRs fore _every_ route-target, > ] | > which does not scale administratively; > ] | > > ] | > --- > ] | > > ] | > what are you concerned about ? storage space in LSPs ? > ] | > > ] | > i guess its fair here to trade some scalability of the protocol > ] | > against convencience. > ] | > > ] | > > ] | > /hannes > ] > ] _______________________________________________ > ] Isis-wg mailing list - Isis-wg@spider.juniper.net > ] http://spider.juniper.net/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 21:58:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28588 for ; Tue, 9 Apr 2002 21:58:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1j1t15143; Tue, 9 Apr 2002 18:45:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39LTYt13919 for ; Tue, 9 Apr 2002 14:29:34 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC854BA21A; Tue, 9 Apr 2002 14:41:23 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 05 Apr 2002 16:22:29 +0200 <20020405162229.A4232@juniper.net> From: Naiming Shen Message-Id: <20020409214123.CDC854BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 14:41:23 -0700 If one is going to make it a 64-bit tag, it maybe good to make it a variable size(n x 32bits) to accommodate future "crazy" applications. ] tx martin for the heads-up; ] ] a customer of mine ran into the following: ] ] inter-AS MPLS VPN, AS2 is the transit AS, ] connected by two BGP border routers each ] [ASBR12, ASBR21, ASBR22 & ASBR31] ] ] AS2(IS-IS) ] / \ ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 ] ] problem: most of the routers in AS1,2,3 do not ] run labeled-BGP, and won't run for a while due ] to various reasons; -so there is only the IGP ] left for delivering the /32s of all the satellite AS ] border routers; ] ] idea: ] ] 1. leak all VPN PE routers /32 from AS3 into ] BGP-labeled-unicast between ASBR22 and ASBR31 ] and tag with a extd. community ] ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is ] not a good idea but these are typically not more than 100s ] of routes) into AS2 IS-IS cloud ] and "conserves" the extd. community as 64-bit tag into IS-IS ] ] 3. ASBR21 extracts the 64-bit tag and translates it back ] into a extd. community on the BGP session between ] ASBR21 and ASBR12 ] ] 4. ASBR12 extracts the community and translates it back into ] IS-IS ] ] --- ] all the above can be done using 32-bit tags i know - however ] it gets complicated as the redistribution policy needs ] to get constantly updated [tag allocation etc.] everytime a new ] AS is added to the transit cloud [read: ISP aquisitions]; ] ] extd.comm->64-bit tag translation policies are very easy to maintain ] [configure & forget] and would retain lots of information where the ] route came from; sure it eats up LSP space however ] i'd like to ask the WG to think about the scalability vs. ] convencience aspect of large tag fields. ] ] /hannes ] ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: ] | Taking it to the WG... ] | ] | To clarify me earlier post wrt to adding additional information. When we ] | originally wrote the draft, we were considering adding 64 byte ACSII ] | remarks. Were we all able to have our cake and eat it too, this would be a ] | good thing. Tony Li was concerned that adding too much information would ] | result in wasted LSP space and faster LSP-space exhaustion (with the ] | corresponding scale-reduction effect). ] | ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC ] | environment is required. ] | ] | Thx, ] | chris ] | ] | ] | ] | ] | -----Original Message----- ] | From: stefano previdi [mailto:sprevidi@cisco.com] ] | Sent: Tuesday, April 02, 2002 8:16 AM ] | To: Hannes Gredler ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 ] | ] | ] | ] | personally, I have no problems with 64 bits. I just think it's not a ] | good idea to make a generic rule just because one particular specific ] | case (that can be solved with 32bits anyway). ] | ] | If the WG is fine with it, I'm fine too. ] | ] | So, please send your comments to the group. ] | ] | s. ] | ] | ] | ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: ] | > | > | > Hannes, ] | > | > | > ] | > | > | > Danny McPherson suggested this some time back. We chose to ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the ] | > | > | > addition of a 64 bit tag makes sense. ] | > | > | ] | > | > | it's the redistribution of BGP routes into isis that doesn't ] | > | > | make ] | > | > | a lot of sense to me. ] | > | > ] | > | > stefano, ] | > | > ] | > | > in native v4 routing i'd agree 100%- however there are ] | > | > interprovider CoC scenarios where redistributing remote-AS PE ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. ] | > | > the more scaleable way three-label pushes is not desireable due to ] | > | > lack of debugging tools [read: MPLS PING], which two-label ] | > | > approaches cleary have; ] | > | > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs ] | > | > into IS-IS, which does not do that much harm as the reflect in a ] | > | > certain sense "infrastructure" routes; ] | > | ] | > | you don't need 8 bytes for this. ] | > ] | > stefano, ] | > ] | > i am not telling that using 32-bit IDs this is not possible, all i am ] | > telling is that tags already assigned via an extended community are ] | > _convenient_; ] | > ] | > policy drafts like your one are all about _convenience_ ] | > e.g. route-leaking is done just fine for a couple of years based on ] | > access lists - however these are cumbersone to maintain and ultimately ] | > you guys have come up with a _convenient_ ways of controlling route ] | > leakage -> i.e. tags; ] | > ] | > in multiprovider VPN setups routes are already tagged by extd. ] | > communities; ] | > ] | > if i want to get routes across my transit-AS i need ] | > to setup two policies at the ASBR for each target; ] | > ] | > 1. extd.community->32-bit route-tag and restore it at ] | > the second border router ] | > ] | > 2. 32-bit route-tag->extd.community in order to ] | > enable "normal" filters based on BGP communities; ] | > ] | > pls note that this procedure need to be done for _every_ route-target; ] | > ] | > --- ] | > ] | > howver for 64-bit tags the AS_wide policy is simple. ] | > ] | > 1. at the first ASBR translate all extd.communities to ] | > 64-bit tags and ] | > 2. translate the 64-bit tags back to communities; ] | > ] | > the adv. is here that i need to setup just one policy ] | > through my AS which stays in place forever; - some sort ] | > of implicit wildcarding; ] | > ] | > in the 32-bit case i need to setup translation policies ] | > on _all_ the ASBRs fore _every_ route-target, ] | > which does not scale administratively; ] | > ] | > --- ] | > ] | > what are you concerned about ? storage space in LSPs ? ] | > ] | > i guess its fair here to trade some scalability of the protocol ] | > against convencience. ] | > ] | > ] | > /hannes ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 22:04:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28746 for ; Tue, 9 Apr 2002 22:04:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A1oMt15187; Tue, 9 Apr 2002 18:50:22 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A0p5t14738 for ; Tue, 9 Apr 2002 17:51:06 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-163-118.cisco.com [128.107.163.118]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id DAA12879; Wed, 10 Apr 2002 03:02:36 +0200 (MET DST) Message-Id: <200204100102.DAA12879@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Hannes Gredler Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 X-Mailer: KMail [version 1.3.1] Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" References: <20020409214123.CDC854BA21A@prattle.redback.com> In-Reply-To: <20020409214123.CDC854BA21A@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3A0p6t14739 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 03:02:32 +0200 Content-Transfer-Encoding: 8bit On Tuesday 09 April 2002 23:41, Naiming Shen wrote: > If one is going to make it a 64-bit tag, it maybe good to make it > a variable size(n x 32bits) to accommodate future "crazy" applications. after some thoughts and discussions it came out that the best way is probably to define one subTLV for 32bits tags and another subTLV for 64bits ones. s. > > ] tx martin for the heads-up; > ] > ] a customer of mine ran into the following: > ] > ] inter-AS MPLS VPN, AS2 is the transit AS, > ] connected by two BGP border routers each > ] [ASBR12, ASBR21, ASBR22 & ASBR31] > ] > ] AS2(IS-IS) > ] / \ > ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 > ] > ] problem: most of the routers in AS1,2,3 do not > ] run labeled-BGP, and won't run for a while due > ] to various reasons; -so there is only the IGP > ] left for delivering the /32s of all the satellite AS > ] border routers; > ] > ] idea: > ] > ] 1. leak all VPN PE routers /32 from AS3 into > ] BGP-labeled-unicast between ASBR22 and ASBR31 > ] and tag with a extd. community > ] > ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is > ] not a good idea but these are typically not more than 100s > ] of routes) into AS2 IS-IS cloud > ] and "conserves" the extd. community as 64-bit tag into IS-IS > ] > ] 3. ASBR21 extracts the 64-bit tag and translates it back > ] into a extd. community on the BGP session between > ] ASBR21 and ASBR12 > ] > ] 4. ASBR12 extracts the community and translates it back into > ] IS-IS > ] > ] --- > ] all the above can be done using 32-bit tags i know - however > ] it gets complicated as the redistribution policy needs > ] to get constantly updated [tag allocation etc.] everytime a new > ] AS is added to the transit cloud [read: ISP aquisitions]; > ] > ] extd.comm->64-bit tag translation policies are very easy to maintain > ] [configure & forget] and would retain lots of information where the > ] route came from; sure it eats up LSP space however > ] i'd like to ask the WG to think about the scalability vs. > ] convencience aspect of large tag fields. > ] > ] /hannes > ] > ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: > ] | Taking it to the WG... > ] | > ] | To clarify me earlier post wrt to adding additional information. When we > ] | originally wrote the draft, we were considering adding 64 byte ACSII > ] | remarks. Were we all able to have our cake and eat it too, this would be > a > ] | good thing. Tony Li was concerned that adding too much information would > ] | result in wasted LSP space and faster LSP-space exhaustion (with the > ] | corresponding scale-reduction effect). > ] | > ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis > ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC > ] | environment is required. > ] | > ] | Thx, > ] | chris > ] | > ] | > ] | > ] | > ] | -----Original Message----- > ] | From: stefano previdi [mailto:sprevidi@cisco.com] > ] | Sent: Tuesday, April 02, 2002 8:16 AM > ] | To: Hannes Gredler > ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; > ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net > ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 > ] | > ] | > ] | > ] | personally, I have no problems with 64 bits. I just think it's not a > ] | good idea to make a generic rule just because one particular specific > ] | case (that can be solved with 32bits anyway). > ] | > ] | If the WG is fine with it, I'm fine too. > ] | > ] | So, please send your comments to the group. > ] | > ] | s. > ] | > ] | > ] | > ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: > ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > ] | > | > | > Hannes, > ] | > | > | > > ] | > | > | > Danny McPherson suggested this some time back. We chose to > ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the > ] | > | > | > addition of a 64 bit tag makes sense. > ] | > | > | > ] | > | > | it's the redistribution of BGP routes into isis that doesn't > ] | > | > | make > ] | > | > | a lot of sense to me. > ] | > | > > ] | > | > stefano, > ] | > | > > ] | > | > in native v4 routing i'd agree 100%- however there are > ] | > | > interprovider CoC scenarios where redistributing remote-AS PE > ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. > ] | > | > the more scaleable way three-label pushes is not desireable due to > ] | > | > lack of debugging tools [read: MPLS PING], which two-label > ] | > | > approaches cleary have; > ] | > | > > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs > ] | > | > into IS-IS, which does not do that much harm as the reflect in a > ] | > | > certain sense "infrastructure" routes; > ] | > | > ] | > | you don't need 8 bytes for this. > ] | > > ] | > stefano, > ] | > > ] | > i am not telling that using 32-bit IDs this is not possible, all i am > ] | > telling is that tags already assigned via an extended community are > ] | > _convenient_; > ] | > > ] | > policy drafts like your one are all about _convenience_ > ] | > e.g. route-leaking is done just fine for a couple of years based on > ] | > access lists - however these are cumbersone to maintain and ultimately > ] | > you guys have come up with a _convenient_ ways of controlling route > ] | > leakage -> i.e. tags; > ] | > > ] | > in multiprovider VPN setups routes are already tagged by extd. > ] | > communities; > ] | > > ] | > if i want to get routes across my transit-AS i need > ] | > to setup two policies at the ASBR for each target; > ] | > > ] | > 1. extd.community->32-bit route-tag and restore it at > ] | > the second border router > ] | > > ] | > 2. 32-bit route-tag->extd.community in order to > ] | > enable "normal" filters based on BGP communities; > ] | > > ] | > pls note that this procedure need to be done for _every_ route-target; > ] | > > ] | > --- > ] | > > ] | > howver for 64-bit tags the AS_wide policy is simple. > ] | > > ] | > 1. at the first ASBR translate all extd.communities to > ] | > 64-bit tags and > ] | > 2. translate the 64-bit tags back to communities; > ] | > > ] | > the adv. is here that i need to setup just one policy > ] | > through my AS which stays in place forever; - some sort > ] | > of implicit wildcarding; > ] | > > ] | > in the 32-bit case i need to setup translation policies > ] | > on _all_ the ASBRs fore _every_ route-target, > ] | > which does not scale administratively; > ] | > > ] | > --- > ] | > > ] | > what are you concerned about ? storage space in LSPs ? > ] | > > ] | > i guess its fair here to trade some scalability of the protocol > ] | > against convencience. > ] | > > ] | > > ] | > /hannes > ] > ] _______________________________________________ > ] Isis-wg mailing list - Isis-wg@spider.juniper.net > ] http://spider.juniper.net/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 22:18:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28892 for ; Tue, 9 Apr 2002 22:18:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A241t15288; Tue, 9 Apr 2002 19:04:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39LTYt13919 for ; Tue, 9 Apr 2002 14:29:34 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC854BA21A; Tue, 9 Apr 2002 14:41:23 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 05 Apr 2002 16:22:29 +0200 <20020405162229.A4232@juniper.net> From: Naiming Shen Message-Id: <20020409214123.CDC854BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 14:41:23 -0700 If one is going to make it a 64-bit tag, it maybe good to make it a variable size(n x 32bits) to accommodate future "crazy" applications. ] tx martin for the heads-up; ] ] a customer of mine ran into the following: ] ] inter-AS MPLS VPN, AS2 is the transit AS, ] connected by two BGP border routers each ] [ASBR12, ASBR21, ASBR22 & ASBR31] ] ] AS2(IS-IS) ] / \ ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 ] ] problem: most of the routers in AS1,2,3 do not ] run labeled-BGP, and won't run for a while due ] to various reasons; -so there is only the IGP ] left for delivering the /32s of all the satellite AS ] border routers; ] ] idea: ] ] 1. leak all VPN PE routers /32 from AS3 into ] BGP-labeled-unicast between ASBR22 and ASBR31 ] and tag with a extd. community ] ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is ] not a good idea but these are typically not more than 100s ] of routes) into AS2 IS-IS cloud ] and "conserves" the extd. community as 64-bit tag into IS-IS ] ] 3. ASBR21 extracts the 64-bit tag and translates it back ] into a extd. community on the BGP session between ] ASBR21 and ASBR12 ] ] 4. ASBR12 extracts the community and translates it back into ] IS-IS ] ] --- ] all the above can be done using 32-bit tags i know - however ] it gets complicated as the redistribution policy needs ] to get constantly updated [tag allocation etc.] everytime a new ] AS is added to the transit cloud [read: ISP aquisitions]; ] ] extd.comm->64-bit tag translation policies are very easy to maintain ] [configure & forget] and would retain lots of information where the ] route came from; sure it eats up LSP space however ] i'd like to ask the WG to think about the scalability vs. ] convencience aspect of large tag fields. ] ] /hannes ] ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: ] | Taking it to the WG... ] | ] | To clarify me earlier post wrt to adding additional information. When we ] | originally wrote the draft, we were considering adding 64 byte ACSII ] | remarks. Were we all able to have our cake and eat it too, this would be a ] | good thing. Tony Li was concerned that adding too much information would ] | result in wasted LSP space and faster LSP-space exhaustion (with the ] | corresponding scale-reduction effect). ] | ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC ] | environment is required. ] | ] | Thx, ] | chris ] | ] | ] | ] | ] | -----Original Message----- ] | From: stefano previdi [mailto:sprevidi@cisco.com] ] | Sent: Tuesday, April 02, 2002 8:16 AM ] | To: Hannes Gredler ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 ] | ] | ] | ] | personally, I have no problems with 64 bits. I just think it's not a ] | good idea to make a generic rule just because one particular specific ] | case (that can be solved with 32bits anyway). ] | ] | If the WG is fine with it, I'm fine too. ] | ] | So, please send your comments to the group. ] | ] | s. ] | ] | ] | ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: ] | > | > | > Hannes, ] | > | > | > ] | > | > | > Danny McPherson suggested this some time back. We chose to ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the ] | > | > | > addition of a 64 bit tag makes sense. ] | > | > | ] | > | > | it's the redistribution of BGP routes into isis that doesn't ] | > | > | make ] | > | > | a lot of sense to me. ] | > | > ] | > | > stefano, ] | > | > ] | > | > in native v4 routing i'd agree 100%- however there are ] | > | > interprovider CoC scenarios where redistributing remote-AS PE ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. ] | > | > the more scaleable way three-label pushes is not desireable due to ] | > | > lack of debugging tools [read: MPLS PING], which two-label ] | > | > approaches cleary have; ] | > | > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs ] | > | > into IS-IS, which does not do that much harm as the reflect in a ] | > | > certain sense "infrastructure" routes; ] | > | ] | > | you don't need 8 bytes for this. ] | > ] | > stefano, ] | > ] | > i am not telling that using 32-bit IDs this is not possible, all i am ] | > telling is that tags already assigned via an extended community are ] | > _convenient_; ] | > ] | > policy drafts like your one are all about _convenience_ ] | > e.g. route-leaking is done just fine for a couple of years based on ] | > access lists - however these are cumbersone to maintain and ultimately ] | > you guys have come up with a _convenient_ ways of controlling route ] | > leakage -> i.e. tags; ] | > ] | > in multiprovider VPN setups routes are already tagged by extd. ] | > communities; ] | > ] | > if i want to get routes across my transit-AS i need ] | > to setup two policies at the ASBR for each target; ] | > ] | > 1. extd.community->32-bit route-tag and restore it at ] | > the second border router ] | > ] | > 2. 32-bit route-tag->extd.community in order to ] | > enable "normal" filters based on BGP communities; ] | > ] | > pls note that this procedure need to be done for _every_ route-target; ] | > ] | > --- ] | > ] | > howver for 64-bit tags the AS_wide policy is simple. ] | > ] | > 1. at the first ASBR translate all extd.communities to ] | > 64-bit tags and ] | > 2. translate the 64-bit tags back to communities; ] | > ] | > the adv. is here that i need to setup just one policy ] | > through my AS which stays in place forever; - some sort ] | > of implicit wildcarding; ] | > ] | > in the 32-bit case i need to setup translation policies ] | > on _all_ the ASBRs fore _every_ route-target, ] | > which does not scale administratively; ] | > ] | > --- ] | > ] | > what are you concerned about ? storage space in LSPs ? ] | > ] | > i guess its fair here to trade some scalability of the protocol ] | > against convencience. ] | > ] | > ] | > /hannes ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 22:23:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28945 for ; Tue, 9 Apr 2002 22:23:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A29Qt15333; Tue, 9 Apr 2002 19:09:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A0p5t14738 for ; Tue, 9 Apr 2002 17:51:06 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-163-118.cisco.com [128.107.163.118]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id DAA12879; Wed, 10 Apr 2002 03:02:36 +0200 (MET DST) Message-Id: <200204100102.DAA12879@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Hannes Gredler Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 X-Mailer: KMail [version 1.3.1] Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" References: <20020409214123.CDC854BA21A@prattle.redback.com> In-Reply-To: <20020409214123.CDC854BA21A@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3A0p6t14739 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 03:02:32 +0200 Content-Transfer-Encoding: 8bit On Tuesday 09 April 2002 23:41, Naiming Shen wrote: > If one is going to make it a 64-bit tag, it maybe good to make it > a variable size(n x 32bits) to accommodate future "crazy" applications. after some thoughts and discussions it came out that the best way is probably to define one subTLV for 32bits tags and another subTLV for 64bits ones. s. > > ] tx martin for the heads-up; > ] > ] a customer of mine ran into the following: > ] > ] inter-AS MPLS VPN, AS2 is the transit AS, > ] connected by two BGP border routers each > ] [ASBR12, ASBR21, ASBR22 & ASBR31] > ] > ] AS2(IS-IS) > ] / \ > ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 > ] > ] problem: most of the routers in AS1,2,3 do not > ] run labeled-BGP, and won't run for a while due > ] to various reasons; -so there is only the IGP > ] left for delivering the /32s of all the satellite AS > ] border routers; > ] > ] idea: > ] > ] 1. leak all VPN PE routers /32 from AS3 into > ] BGP-labeled-unicast between ASBR22 and ASBR31 > ] and tag with a extd. community > ] > ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is > ] not a good idea but these are typically not more than 100s > ] of routes) into AS2 IS-IS cloud > ] and "conserves" the extd. community as 64-bit tag into IS-IS > ] > ] 3. ASBR21 extracts the 64-bit tag and translates it back > ] into a extd. community on the BGP session between > ] ASBR21 and ASBR12 > ] > ] 4. ASBR12 extracts the community and translates it back into > ] IS-IS > ] > ] --- > ] all the above can be done using 32-bit tags i know - however > ] it gets complicated as the redistribution policy needs > ] to get constantly updated [tag allocation etc.] everytime a new > ] AS is added to the transit cloud [read: ISP aquisitions]; > ] > ] extd.comm->64-bit tag translation policies are very easy to maintain > ] [configure & forget] and would retain lots of information where the > ] route came from; sure it eats up LSP space however > ] i'd like to ask the WG to think about the scalability vs. > ] convencience aspect of large tag fields. > ] > ] /hannes > ] > ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: > ] | Taking it to the WG... > ] | > ] | To clarify me earlier post wrt to adding additional information. When we > ] | originally wrote the draft, we were considering adding 64 byte ACSII > ] | remarks. Were we all able to have our cake and eat it too, this would be > a > ] | good thing. Tony Li was concerned that adding too much information would > ] | result in wasted LSP space and faster LSP-space exhaustion (with the > ] | corresponding scale-reduction effect). > ] | > ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis > ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC > ] | environment is required. > ] | > ] | Thx, > ] | chris > ] | > ] | > ] | > ] | > ] | -----Original Message----- > ] | From: stefano previdi [mailto:sprevidi@cisco.com] > ] | Sent: Tuesday, April 02, 2002 8:16 AM > ] | To: Hannes Gredler > ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; > ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net > ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 > ] | > ] | > ] | > ] | personally, I have no problems with 64 bits. I just think it's not a > ] | good idea to make a generic rule just because one particular specific > ] | case (that can be solved with 32bits anyway). > ] | > ] | If the WG is fine with it, I'm fine too. > ] | > ] | So, please send your comments to the group. > ] | > ] | s. > ] | > ] | > ] | > ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: > ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > ] | > | > | > Hannes, > ] | > | > | > > ] | > | > | > Danny McPherson suggested this some time back. We chose to > ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the > ] | > | > | > addition of a 64 bit tag makes sense. > ] | > | > | > ] | > | > | it's the redistribution of BGP routes into isis that doesn't > ] | > | > | make > ] | > | > | a lot of sense to me. > ] | > | > > ] | > | > stefano, > ] | > | > > ] | > | > in native v4 routing i'd agree 100%- however there are > ] | > | > interprovider CoC scenarios where redistributing remote-AS PE > ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. > ] | > | > the more scaleable way three-label pushes is not desireable due to > ] | > | > lack of debugging tools [read: MPLS PING], which two-label > ] | > | > approaches cleary have; > ] | > | > > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs > ] | > | > into IS-IS, which does not do that much harm as the reflect in a > ] | > | > certain sense "infrastructure" routes; > ] | > | > ] | > | you don't need 8 bytes for this. > ] | > > ] | > stefano, > ] | > > ] | > i am not telling that using 32-bit IDs this is not possible, all i am > ] | > telling is that tags already assigned via an extended community are > ] | > _convenient_; > ] | > > ] | > policy drafts like your one are all about _convenience_ > ] | > e.g. route-leaking is done just fine for a couple of years based on > ] | > access lists - however these are cumbersone to maintain and ultimately > ] | > you guys have come up with a _convenient_ ways of controlling route > ] | > leakage -> i.e. tags; > ] | > > ] | > in multiprovider VPN setups routes are already tagged by extd. > ] | > communities; > ] | > > ] | > if i want to get routes across my transit-AS i need > ] | > to setup two policies at the ASBR for each target; > ] | > > ] | > 1. extd.community->32-bit route-tag and restore it at > ] | > the second border router > ] | > > ] | > 2. 32-bit route-tag->extd.community in order to > ] | > enable "normal" filters based on BGP communities; > ] | > > ] | > pls note that this procedure need to be done for _every_ route-target; > ] | > > ] | > --- > ] | > > ] | > howver for 64-bit tags the AS_wide policy is simple. > ] | > > ] | > 1. at the first ASBR translate all extd.communities to > ] | > 64-bit tags and > ] | > 2. translate the 64-bit tags back to communities; > ] | > > ] | > the adv. is here that i need to setup just one policy > ] | > through my AS which stays in place forever; - some sort > ] | > of implicit wildcarding; > ] | > > ] | > in the 32-bit case i need to setup translation policies > ] | > on _all_ the ASBRs fore _every_ route-target, > ] | > which does not scale administratively; > ] | > > ] | > --- > ] | > > ] | > what are you concerned about ? storage space in LSPs ? > ] | > > ] | > i guess its fair here to trade some scalability of the protocol > ] | > against convencience. > ] | > > ] | > > ] | > /hannes > ] > ] _______________________________________________ > ] Isis-wg mailing list - Isis-wg@spider.juniper.net > ] http://spider.juniper.net/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 22:37:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00008 for ; Tue, 9 Apr 2002 22:37:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A2N0t15424; Tue, 9 Apr 2002 19:23:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g39LTYt13919 for ; Tue, 9 Apr 2002 14:29:34 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC854BA21A; Tue, 9 Apr 2002 14:41:23 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'stefano previdi'" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 05 Apr 2002 16:22:29 +0200 <20020405162229.A4232@juniper.net> From: Naiming Shen Message-Id: <20020409214123.CDC854BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 14:41:23 -0700 If one is going to make it a 64-bit tag, it maybe good to make it a variable size(n x 32bits) to accommodate future "crazy" applications. ] tx martin for the heads-up; ] ] a customer of mine ran into the following: ] ] inter-AS MPLS VPN, AS2 is the transit AS, ] connected by two BGP border routers each ] [ASBR12, ASBR21, ASBR22 & ASBR31] ] ] AS2(IS-IS) ] / \ ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 ] ] problem: most of the routers in AS1,2,3 do not ] run labeled-BGP, and won't run for a while due ] to various reasons; -so there is only the IGP ] left for delivering the /32s of all the satellite AS ] border routers; ] ] idea: ] ] 1. leak all VPN PE routers /32 from AS3 into ] BGP-labeled-unicast between ASBR22 and ASBR31 ] and tag with a extd. community ] ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is ] not a good idea but these are typically not more than 100s ] of routes) into AS2 IS-IS cloud ] and "conserves" the extd. community as 64-bit tag into IS-IS ] ] 3. ASBR21 extracts the 64-bit tag and translates it back ] into a extd. community on the BGP session between ] ASBR21 and ASBR12 ] ] 4. ASBR12 extracts the community and translates it back into ] IS-IS ] ] --- ] all the above can be done using 32-bit tags i know - however ] it gets complicated as the redistribution policy needs ] to get constantly updated [tag allocation etc.] everytime a new ] AS is added to the transit cloud [read: ISP aquisitions]; ] ] extd.comm->64-bit tag translation policies are very easy to maintain ] [configure & forget] and would retain lots of information where the ] route came from; sure it eats up LSP space however ] i'd like to ask the WG to think about the scalability vs. ] convencience aspect of large tag fields. ] ] /hannes ] ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: ] | Taking it to the WG... ] | ] | To clarify me earlier post wrt to adding additional information. When we ] | originally wrote the draft, we were considering adding 64 byte ACSII ] | remarks. Were we all able to have our cake and eat it too, this would be a ] | good thing. Tony Li was concerned that adding too much information would ] | result in wasted LSP space and faster LSP-space exhaustion (with the ] | corresponding scale-reduction effect). ] | ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC ] | environment is required. ] | ] | Thx, ] | chris ] | ] | ] | ] | ] | -----Original Message----- ] | From: stefano previdi [mailto:sprevidi@cisco.com] ] | Sent: Tuesday, April 02, 2002 8:16 AM ] | To: Hannes Gredler ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 ] | ] | ] | ] | personally, I have no problems with 64 bits. I just think it's not a ] | good idea to make a generic rule just because one particular specific ] | case (that can be solved with 32bits anyway). ] | ] | If the WG is fine with it, I'm fine too. ] | ] | So, please send your comments to the group. ] | ] | s. ] | ] | ] | ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: ] | > | > | > Hannes, ] | > | > | > ] | > | > | > Danny McPherson suggested this some time back. We chose to ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the ] | > | > | > addition of a 64 bit tag makes sense. ] | > | > | ] | > | > | it's the redistribution of BGP routes into isis that doesn't ] | > | > | make ] | > | > | a lot of sense to me. ] | > | > ] | > | > stefano, ] | > | > ] | > | > in native v4 routing i'd agree 100%- however there are ] | > | > interprovider CoC scenarios where redistributing remote-AS PE ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. ] | > | > the more scaleable way three-label pushes is not desireable due to ] | > | > lack of debugging tools [read: MPLS PING], which two-label ] | > | > approaches cleary have; ] | > | > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs ] | > | > into IS-IS, which does not do that much harm as the reflect in a ] | > | > certain sense "infrastructure" routes; ] | > | ] | > | you don't need 8 bytes for this. ] | > ] | > stefano, ] | > ] | > i am not telling that using 32-bit IDs this is not possible, all i am ] | > telling is that tags already assigned via an extended community are ] | > _convenient_; ] | > ] | > policy drafts like your one are all about _convenience_ ] | > e.g. route-leaking is done just fine for a couple of years based on ] | > access lists - however these are cumbersone to maintain and ultimately ] | > you guys have come up with a _convenient_ ways of controlling route ] | > leakage -> i.e. tags; ] | > ] | > in multiprovider VPN setups routes are already tagged by extd. ] | > communities; ] | > ] | > if i want to get routes across my transit-AS i need ] | > to setup two policies at the ASBR for each target; ] | > ] | > 1. extd.community->32-bit route-tag and restore it at ] | > the second border router ] | > ] | > 2. 32-bit route-tag->extd.community in order to ] | > enable "normal" filters based on BGP communities; ] | > ] | > pls note that this procedure need to be done for _every_ route-target; ] | > ] | > --- ] | > ] | > howver for 64-bit tags the AS_wide policy is simple. ] | > ] | > 1. at the first ASBR translate all extd.communities to ] | > 64-bit tags and ] | > 2. translate the 64-bit tags back to communities; ] | > ] | > the adv. is here that i need to setup just one policy ] | > through my AS which stays in place forever; - some sort ] | > of implicit wildcarding; ] | > ] | > in the 32-bit case i need to setup translation policies ] | > on _all_ the ASBRs fore _every_ route-target, ] | > which does not scale administratively; ] | > ] | > --- ] | > ] | > what are you concerned about ? storage space in LSPs ? ] | > ] | > i guess its fair here to trade some scalability of the protocol ] | > against convencience. ] | > ] | > ] | > /hannes ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 9 22:47:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00198 for ; Tue, 9 Apr 2002 22:47:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A2T9t15497; Tue, 9 Apr 2002 19:29:09 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A0p5t14738 for ; Tue, 9 Apr 2002 17:51:06 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-163-118.cisco.com [128.107.163.118]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id DAA12879; Wed, 10 Apr 2002 03:02:36 +0200 (MET DST) Message-Id: <200204100102.DAA12879@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Hannes Gredler Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 X-Mailer: KMail [version 1.3.1] Cc: "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" References: <20020409214123.CDC854BA21A@prattle.redback.com> In-Reply-To: <20020409214123.CDC854BA21A@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3A0p6t14739 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 03:02:32 +0200 Content-Transfer-Encoding: 8bit On Tuesday 09 April 2002 23:41, Naiming Shen wrote: > If one is going to make it a 64-bit tag, it maybe good to make it > a variable size(n x 32bits) to accommodate future "crazy" applications. after some thoughts and discussions it came out that the best way is probably to define one subTLV for 32bits tags and another subTLV for 64bits ones. s. > > ] tx martin for the heads-up; > ] > ] a customer of mine ran into the following: > ] > ] inter-AS MPLS VPN, AS2 is the transit AS, > ] connected by two BGP border routers each > ] [ASBR12, ASBR21, ASBR22 & ASBR31] > ] > ] AS2(IS-IS) > ] / \ > ] AS1--ISIS--ASBR12-BGP-ASBR21 ASBR22-BGP-ASBR31--ISIS--AS3 > ] > ] problem: most of the routers in AS1,2,3 do not > ] run labeled-BGP, and won't run for a while due > ] to various reasons; -so there is only the IGP > ] left for delivering the /32s of all the satellite AS > ] border routers; > ] > ] idea: > ] > ] 1. leak all VPN PE routers /32 from AS3 into > ] BGP-labeled-unicast between ASBR22 and ASBR31 > ] and tag with a extd. community > ] > ] 2. ASBR22 redistributes (yes i know BGP IGP distribution is > ] not a good idea but these are typically not more than 100s > ] of routes) into AS2 IS-IS cloud > ] and "conserves" the extd. community as 64-bit tag into IS-IS > ] > ] 3. ASBR21 extracts the 64-bit tag and translates it back > ] into a extd. community on the BGP session between > ] ASBR21 and ASBR12 > ] > ] 4. ASBR12 extracts the community and translates it back into > ] IS-IS > ] > ] --- > ] all the above can be done using 32-bit tags i know - however > ] it gets complicated as the redistribution policy needs > ] to get constantly updated [tag allocation etc.] everytime a new > ] AS is added to the transit cloud [read: ISP aquisitions]; > ] > ] extd.comm->64-bit tag translation policies are very easy to maintain > ] [configure & forget] and would retain lots of information where the > ] route came from; sure it eats up LSP space however > ] i'd like to ask the WG to think about the scalability vs. > ] convencience aspect of large tag fields. > ] > ] /hannes > ] > ] On Tue, Apr 02, 2002 at 12:47:20PM -0500, Martin, Christian wrote: > ] | Taking it to the WG... > ] | > ] | To clarify me earlier post wrt to adding additional information. When we > ] | originally wrote the draft, we were considering adding 64 byte ACSII > ] | remarks. Were we all able to have our cake and eat it too, this would be > a > ] | good thing. Tony Li was concerned that adding too much information would > ] | result in wasted LSP space and faster LSP-space exhaustion (with the > ] | corresponding scale-reduction effect). > ] | > ] | Hannes, can you clarify the scenario you are presenting? From a 2547bis > ] | perspective, I don't see how carrying VPNv4 routes in IS-IS in a CoC > ] | environment is required. > ] | > ] | Thx, > ] | chris > ] | > ] | > ] | > ] | > ] | -----Original Message----- > ] | From: stefano previdi [mailto:sprevidi@cisco.com] > ] | Sent: Tuesday, April 02, 2002 8:16 AM > ] | To: Hannes Gredler > ] | Cc: Martin, Christian; bneal@broadwing.com; kireeti@juniper.net; > ] | nsheth@juniper.net; yakov@juniper.net; danny@tcb.net > ] | Subject: Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 > ] | > ] | > ] | > ] | personally, I have no problems with 64 bits. I just think it's not a > ] | good idea to make a generic rule just because one particular specific > ] | case (that can be solved with 32bits anyway). > ] | > ] | If the WG is fine with it, I'm fine too. > ] | > ] | So, please send your comments to the group. > ] | > ] | s. > ] | > ] | > ] | > ] | On Monday 01 April 2002 22:33, Hannes Gredler wrote: > ] | > On Mon, Apr 01, 2002 at 12:36:27PM +0100, stefano previdi wrote: > ] | > | On Monday 01 April 2002 10:39, Hannes Gredler wrote: > ] | > | > On Mon, Apr 01, 2002 at 09:17:25AM +0100, stefano previdi wrote: > ] | > | > | On Monday 01 April 2002 02:18, Martin, Christian wrote: > ] | > | > | > Hannes, > ] | > | > | > > ] | > | > | > Danny McPherson suggested this some time back. We chose to > ] | > | > | > stay at 32 bits to be comparable to OSPF tags, but the > ] | > | > | > addition of a 64 bit tag makes sense. > ] | > | > | > ] | > | > | it's the redistribution of BGP routes into isis that doesn't > ] | > | > | make > ] | > | > | a lot of sense to me. > ] | > | > > ] | > | > stefano, > ] | > | > > ] | > | > in native v4 routing i'd agree 100%- however there are > ] | > | > interprovider CoC scenarios where redistributing remote-AS PE > ] | > | > routers into ISIS/LDP is the only way to get a two-label stack. > ] | > | > the more scaleable way three-label pushes is not desireable due to > ] | > | > lack of debugging tools [read: MPLS PING], which two-label > ] | > | > approaches cleary have; > ] | > | > > ] | > | > so my client decided to redistribute the few hundred remote-AS PEs > ] | > | > into IS-IS, which does not do that much harm as the reflect in a > ] | > | > certain sense "infrastructure" routes; > ] | > | > ] | > | you don't need 8 bytes for this. > ] | > > ] | > stefano, > ] | > > ] | > i am not telling that using 32-bit IDs this is not possible, all i am > ] | > telling is that tags already assigned via an extended community are > ] | > _convenient_; > ] | > > ] | > policy drafts like your one are all about _convenience_ > ] | > e.g. route-leaking is done just fine for a couple of years based on > ] | > access lists - however these are cumbersone to maintain and ultimately > ] | > you guys have come up with a _convenient_ ways of controlling route > ] | > leakage -> i.e. tags; > ] | > > ] | > in multiprovider VPN setups routes are already tagged by extd. > ] | > communities; > ] | > > ] | > if i want to get routes across my transit-AS i need > ] | > to setup two policies at the ASBR for each target; > ] | > > ] | > 1. extd.community->32-bit route-tag and restore it at > ] | > the second border router > ] | > > ] | > 2. 32-bit route-tag->extd.community in order to > ] | > enable "normal" filters based on BGP communities; > ] | > > ] | > pls note that this procedure need to be done for _every_ route-target; > ] | > > ] | > --- > ] | > > ] | > howver for 64-bit tags the AS_wide policy is simple. > ] | > > ] | > 1. at the first ASBR translate all extd.communities to > ] | > 64-bit tags and > ] | > 2. translate the 64-bit tags back to communities; > ] | > > ] | > the adv. is here that i need to setup just one policy > ] | > through my AS which stays in place forever; - some sort > ] | > of implicit wildcarding; > ] | > > ] | > in the 32-bit case i need to setup translation policies > ] | > on _all_ the ASBRs fore _every_ route-target, > ] | > which does not scale administratively; > ] | > > ] | > --- > ] | > > ] | > what are you concerned about ? storage space in LSPs ? > ] | > > ] | > i guess its fair here to trade some scalability of the protocol > ] | > against convencience. > ] | > > ] | > > ] | > /hannes > ] > ] _______________________________________________ > ] Isis-wg mailing list - Isis-wg@spider.juniper.net > ] http://spider.juniper.net/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 10 08:23:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16502 for ; Wed, 10 Apr 2002 08:23:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3AC71t18787; Wed, 10 Apr 2002 05:07:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3AC5wt18767 for ; Wed, 10 Apr 2002 05:05:58 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3ACHp656179 for ; Wed, 10 Apr 2002 05:17:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 10 Apr 2002 05:11:15 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16109; Wed, 10 Apr 2002 08:12:57 -0400 (EDT) Message-Id: <200204101212.IAA16109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 10 Apr 2002 12:11:15.0764 (UTC) FILETIME=[D0480740:01C1E088] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 08:12:57 -0400 --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 Routing in IS-IS Author(s) : T. Przygienda, N. Shen, N. Sheth Filename : draft-ietf-isis-wg-multi-topology-03.txt Pages : 7 Date : 09-Apr-02 This draft describes an optional implementation technique within IS-IS used today by many ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs), or Multiple views of Topology. 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, force a subset of an address space to follow a different topology, or even maintain a restricted number of protocol based VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-multi-topology-03.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-03.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: <20020409132306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020409132306.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 10 08:38:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17270 for ; Wed, 10 Apr 2002 08:38:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ACJJt18862; Wed, 10 Apr 2002 05:19:19 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3AC5wt18772 for ; Wed, 10 Apr 2002 05:05:58 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3ACHp656183 for ; Wed, 10 Apr 2002 05:17:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 10 Apr 2002 05:12:01 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16243; Wed, 10 Apr 2002 08:13:43 -0400 (EDT) Message-Id: <200204101213.IAA16243@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 10 Apr 2002 12:12:01.0655 (UTC) FILETIME=[EBA27070:01C1E088] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-lsp-frags-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 08:13:43 -0400 --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 : Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Author(s) : A. Hermelin, S. Previdi, M. Shand Filename : draft-ietf-isis-ext-lsp-frags-00.txt Pages : 10 Date : 09-Apr-02 This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-lsp-frags-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ext-lsp-frags-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-ietf-isis-ext-lsp-frags-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. --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: <20020409133730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-lsp-frags-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-lsp-frags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020409133730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 11 16:00:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12106 for ; Thu, 11 Apr 2002 16:00:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BJi1t27634; Thu, 11 Apr 2002 12:44:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BJhFt27622 for ; Thu, 11 Apr 2002 12:43:15 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id <2L36R4MD>; Thu, 11 Apr 2002 15:55:16 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2D85@entmail.gnilink.com> From: "Martin, Christian" To: "'Tony Przygienda'" , "Martin, Christian" Cc: "'stefano previdi'" , Hannes Gredler , bneal@broadwing.com, Tony Li , naiming@redback.com, Nischal Sheth , "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Apr 2002 15:55:11 -0400 Tony, I think we are clear. A few more questions for the group, inline. >Christian, > >Inbetween my ramblings, a little unordered > >> >> > >> > why don't you add the multi-topology to the list. It's >aligned with >> > the TE draft. You can mention the prefix color already contained >> > within as an orthogonal issue. >> >> Do you mean the draft as a reference? > >I actually thought you would list MT TLVs as being able to >contain those sub-TLVs as you list the TLVs of the TE draft >for example. Got it now - I am adding the subTLVs to TLV 235. >> Also, should we reserve tag space for future use, a la communities? >> 0xFF000000 to 0xFFFFFFFF? Same for Extcomms? Further, are we being >> agnostic to the contents of a 64-bit tag (and a 32 bit tag), >or are we >> saying that the 64 bit tag is to carry ext-communities? In these >> cases, the ordering is important, IMO. > >I had the suspicion that's why I brought the issue up. That's >why I would like to see text explaining whether you guys make >assumptions about ordering, what duplicate valuies within same >sub-TLV mean and whether you can have and what the semantics >of multiple instances of a sub-TLV mean. And I think best is >to not to make the draft normalize anything in terms of those >things and leave it over to the application and maybe add as >example describe your scenario where the application (ext. >comm-tag translation) assumes ordering. As I see it, it is similar to a community string, rather than an AS PATH. There is an implied ordering, and the ordering should be preserved (which it must because the LSP shouldn't get rewritten or rebuilt). If one were to change the tag at, say, an abr, the checksum could change. I am not sure if the checksum should change in an LSP! Which brings me to the area of summarization. If multiple TLV 135s with SubTLV 1 or 2 are contributing to the aggregate, what do we do with the aggregate's tags? If we take the community approach, we would merge all the tags or wipe them. However, merging them could pose scaling problems. Is it necessary? What about if we take the intersection of all tags, such that there is no overlap and no duplication? Then again, for simplicity, we can just wipe the tags at the summarization point, as is done with atomic aggregates. Further, if we are to define a tag for communities, does this need to be stated explicitly? As I see it, the interpretation is implementation and situation-dependent. If all are in agreement, I will remove this ambiguity with an explicit statement as such. >Reserving tag-space is a fine idea albeit I would probably not >put it into a draft, too restrictive for other deployment >approaches IMO. Agreed. The implied reservations from the communities would be sufficient. For simple dimensionless tags, no need for reservation. >I don't think that e.g. indicating whether the set is ordered >or not is necessary but we could do it by stealing e.g. one >bit from the sub-TLV length. But then pretty soon you end up >in the discussion with BGP attribute problem, so e.g. is it >mandatory to understand those tags & so on. Not productive really. > > >> >From an operational perspective, we use community ordering and rely >> >upon >> matching rules that expect ordering. The use of tags for community >> support implies a string or sequence, which was not the original >> intention. Were it so, then the wording should change to >indicate as >> such. >> >> > Otherwise if different implementations make assumptions about what >> > duplicates mean or assume ordering of tags, you may end up with >> > interoperability problems. >> >> We should clarify this now before resubmittal. > >that was my idea. I know my comments are slightly 'meta' but I >kind of blindly try to apply pattern matching in terms of >having seen same kind of structures in other protocol designs >and the problems that came out from >over- or underspecification of those structures. I got a clear >match here ;-) Thanks for sharing your insight! chris >Summarizing, IMO >if you care for interoperable implementations, I would spell >out the assumptions or lack thereof and maybe give your example. > > thanks > > - tony > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 11 19:18:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19762 for ; Thu, 11 Apr 2002 19:18:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BN3ht28580; Thu, 11 Apr 2002 16:03:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BMxAt28551 for ; Thu, 11 Apr 2002 15:59:10 -0700 (PDT) (envelope-from hannes@ghostrider.gredler.at) Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id BAA30296; Fri, 12 Apr 2002 01:10:47 +0200 From: Hannes Gredler To: "Martin, Christian" Cc: "'Tony Przygienda'" , "'stefano previdi'" , bneal@broadwing.com, Tony Li , naiming@redback.com, Nischal Sheth , "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 Message-ID: <20020412011047.A30283@juniper.net> References: <94B9091E1149D411A45C00508BACEB35015F2D85@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <94B9091E1149D411A45C00508BACEB35015F2D85@entmail.gnilink.com>; from cmartin@gnilink.net on Thu, Apr 11, 2002 at 03:55:11PM -0400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 12 Apr 2002 01:10:47 +0200 On Thu, Apr 11, 2002 at 03:55:11PM -0400, Martin, Christian wrote: | Which brings me to the area of summarization. If multiple TLV 135s with | SubTLV 1 or 2 are contributing to the aggregate, what do we do with the | aggregate's tags? If we take the community approach, we would merge all the | tags or wipe them. However, merging them could pose scaling problems. Is | it necessary? What about if we take the intersection of all tags, such that | there is no overlap and no duplication? Then again, for simplicity, we can | just wipe the tags at the summarization point, as is done with atomic | aggregates. maybe i am too radical towards aggregates, but IMHO an aggregate is a new route and thus all the tags should get removed; (solves also the scaling problem) the particular problem we are trying to solve using admin-tags is to control the flow of /32 routes - the aggregate discussion is really a corner-case in that respect; from a implementation point you can always define via local-policy what admin-tags should be included/suppressed in the aggregate; | Further, if we are to define a tag for communities, does this need to be | stated explicitly? As I see it, the interpretation is implementation and | situation-dependent. If all are in agreement, I will remove this ambiguity | with an explicit statement as such. i am fine with removing the ambiguity; /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 11 19:47:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20269 for ; Thu, 11 Apr 2002 19:47:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BNXPt28746; Thu, 11 Apr 2002 16:33:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3BNP2t28706 for ; Thu, 11 Apr 2002 16:25:02 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B9118262817; Thu, 11 Apr 2002 16:37:04 -0700 (PDT) To: Hannes Gredler Cc: "Martin, Christian" , "'Tony Przygienda'" , "'stefano previdi'" , bneal@broadwing.com, Tony Li , Nischal Sheth , "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from Hannes Gredler dated Fri, 12 Apr 2002 01:10:47 +0200 <20020412011047.A30283@juniper.net> From: Naiming Shen Message-Id: <20020411233704.B9118262817@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Apr 2002 16:37:04 -0700 I agree. this tag tlv is only defined in ISIS LSP, how to inject to or extract the meaning from the tags for each individual isis route is an implementation and configuration issue. For summarization, there may exist a reverse issue, if seeing this kind of tag, then don't summerize it during route leaking or redistribution for example, but that's also a local config policy issue. thanks. ] On Thu, Apr 11, 2002 at 03:55:11PM -0400, Martin, Christian wrote: ] ] | Which brings me to the area of summarization. If multiple TLV 135s with ] | SubTLV 1 or 2 are contributing to the aggregate, what do we do with the ] | aggregate's tags? If we take the community approach, we would merge all t he ] | tags or wipe them. However, merging them could pose scaling problems. Is ] | it necessary? What about if we take the intersection of all tags, such th at ] | there is no overlap and no duplication? Then again, for simplicity, we ca n ] | just wipe the tags at the summarization point, as is done with atomic ] | aggregates. ] ] maybe i am too radical towards aggregates, but IMHO an aggregate is a new ] route and thus all the tags should get removed; (solves also the scaling ] problem) ] ] the particular problem we are trying to solve using admin-tags is ] to control the flow of /32 routes - the aggregate discussion ] is really a corner-case in that respect; ] ] from a implementation point you can always define via local-policy ] what admin-tags should be included/suppressed in the aggregate; ] ] | Further, if we are to define a tag for communities, does this need to be ] | stated explicitly? As I see it, the interpretation is implementation and ] | situation-dependent. If all are in agreement, I will remove this ambiguit y ] | with an explicit statement as such. ] ] i am fine with removing the ambiguity; ] ] /hannes - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 11 23:25:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10433 for ; Thu, 11 Apr 2002 23:25:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3C3APt29788; Thu, 11 Apr 2002 20:10:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3C345t29750 for ; Thu, 11 Apr 2002 20:04:05 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com ([63.200.48.146]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GUF004SDQEVTX@mta6.snfc21.pbi.net> for isis-wg@external.juniper.net; Thu, 11 Apr 2002 20:16:08 -0700 (PDT) From: Tony Przygienda To: "Martin, Christian" Cc: "'stefano previdi'" , Hannes Gredler , bneal@broadwing.com, Tony Li , naiming@redback.com, Nischal Sheth , "'isis-wg@external.juniper.net'" Message-id: <3CB6322B.8ABF1069@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <94B9091E1149D411A45C00508BACEB35015F2D85@entmail.gnilink.com> Subject: [Isis-wg] Re: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Apr 2002 18:02:35 -0700 Content-Transfer-Encoding: 7BIT "Martin, Christian" wrote: > Tony, I think we are clear. A few more questions for the group, inline. > > > >I actually thought you would list MT TLVs as being able to > >contain those sub-TLVs as you list the TLVs of the TE draft > >for example. > > Got it now - I am adding the subTLVs to TLV 235. > ok > > > >I had the suspicion that's why I brought the issue up. That's > >why I would like to see text explaining whether you guys make > >assumptions about ordering, what duplicate valuies within same > >sub-TLV mean and whether you can have and what the semantics > >of multiple instances of a sub-TLV mean. And I think best is > >to not to make the draft normalize anything in terms of those > >things and leave it over to the application and maybe add as > >example describe your scenario where the application (ext. > >comm-tag translation) assumes ordering. > > As I see it, it is similar to a community string, rather than an AS PATH. > There is an implied ordering, and the ordering should be preserved (which it > must because the LSP shouldn't get rewritten or rebuilt). If one were to > change the tag at, say, an abr, the checksum could change. I am not sure if > the checksum should change in an LSP! ok, so if you care for people to interoperate with your vendor of choice for this particualr application of tags, spell that stuff out in an example in the draft I would say. > Which brings me to the area of summarization. If multiple TLV 135s with > SubTLV 1 or 2 are contributing to the aggregate, what do we do with the > aggregate's tags? If we take the community approach, we would merge all the > tags or wipe them. However, merging them could pose scaling problems. Is > it necessary? What about if we take the intersection of all tags, such that > there is no overlap and no duplication? Then again, for simplicity, we can > just wipe the tags at the summarization point, as is done with atomic > aggregates. > > Further, if we are to define a tag for communities, does this need to be > stated explicitly? As I see it, the interpretation is implementation and > situation-dependent. If all are in agreement, I will remove this ambiguity > with an explicit statement as such. let's not make that stuff BGP, I think there's anothe rthread going on already on this stuff but that is one hairy can of worms we're getting in here. I would agree with Naiming that it is a local policy and default behavior is to not put anything on summary thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Apr 14 03:23:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15069 for ; Sun, 14 Apr 2002 03:23:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3E761t45840; Sun, 14 Apr 2002 00:06:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3E75Wt45828 for ; Sun, 14 Apr 2002 00:05:32 -0700 (PDT) (envelope-from /aimcque/jmail.rcv/0/jm3c3cb92cd5@hongkong.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3E7Hmn28748 for ; Sun, 14 Apr 2002 00:17:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from hongkong.com ([202.84.12.153]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 14 Apr 2002 00:12:32 -0700 Received: from hongkong.com([10.1.0.101]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm3c3cb92cd5; Sun, 14 Apr 2002 06:58:46 -0000 Received: from loki.ietf.org([132.151.1.177]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jma43cb43c3a; Wed, 10 Apr 2002 13:00:25 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26799 for ietf-123-outbound.03@ietf.org; Wed, 10 Apr 2002 08:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA26434 for ; Wed, 10 Apr 2002 08:13:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16109; Wed, 10 Apr 2002 08:12:57 -0400 (EDT) Message-Id: <200204101212.IAA16109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-Auto-Forward: nicklau@hongkong.com X-OriginalArrivalTime: 14 Apr 2002 07:12:32.0327 (UTC) FILETIME=[BEBB9570:01C1E383] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 08:12:57 -0400 --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 Routing in IS-IS Author(s) : T. Przygienda, N. Shen, N. Sheth Filename : draft-ietf-isis-wg-multi-topology-03.txt Pages : 7 Date : 09-Apr-02 This draft describes an optional implementation technique within IS-IS used today by many ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs), or Multiple views of Topology. 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, force a subset of an address space to follow a different topology, or even maintain a restricted number of protocol based VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-multi-topology-03.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-03.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: <20020409132306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020409132306.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Apr 14 06:49:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16644 for ; Sun, 14 Apr 2002 06:49:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3EAYPt47294; Sun, 14 Apr 2002 03:34:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3EAPPt47241 for ; Sun, 14 Apr 2002 03:25:25 -0700 (PDT) (envelope-from Internet-Drafts@ietf.org) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3EAbhn29900 for ; Sun, 14 Apr 2002 03:37:43 -0700 (PDT) X-JNPR-Received-From: outside Received: from hongkong.com ([202.84.12.154]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 14 Apr 2002 03:32:48 -0700 Received: from hongkong.com([10.1.0.100]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm73cb9a056; Sun, 14 Apr 2002 10:28:40 -0000 Received: from loki.ietf.org([132.151.1.177]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jmac3cb49bc3; Wed, 10 Apr 2002 14:01:39 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA27381 for ietf-123-outbound.03@ietf.org; Wed, 10 Apr 2002 10:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA26485 for ; Wed, 10 Apr 2002 08:13:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16243; Wed, 10 Apr 2002 08:13:43 -0400 (EDT) Message-Id: <200204101213.IAA16243@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-Auto-Forward: nicklau@hongkong.com nicklau@speednet.net X-OriginalArrivalTime: 14 Apr 2002 10:32:48.0702 (UTC) FILETIME=[B90CE5E0:01C1E39F] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-lsp-frags-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 08:13:43 -0400 --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 : Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Author(s) : A. Hermelin, S. Previdi, M. Shand Filename : draft-ietf-isis-ext-lsp-frags-00.txt Pages : 10 Date : 09-Apr-02 This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-lsp-frags-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ext-lsp-frags-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-ietf-isis-ext-lsp-frags-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. --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: <20020409133730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-lsp-frags-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-lsp-frags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020409133730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 15 05:54:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11025 for ; Mon, 15 Apr 2002 05:54:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3F9c1t53790; Mon, 15 Apr 2002 02:38:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3F9adt53768 for ; Mon, 15 Apr 2002 02:36:39 -0700 (PDT) (envelope-from nagij@netplane.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3F9n3n41909 for ; Mon, 15 Apr 2002 02:49:03 -0700 (PDT) X-JNPR-Received-From: outside Received: from xover.netplane.com ([198.62.10.2]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 02:45:24 -0700 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR2308>; Mon, 15 Apr 2002 05:47:11 -0400 Message-ID: From: "Jonnala, Nagi" To: "'tli@procket.net'" , "'rja@extremenetworks.com'" Cc: "'isis-wg@juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Apr 2002 09:45:24.0828 (UTC) FILETIME=[4461E9C0:01C1E462] Subject: [Isis-wg] ISIS Cryptographic Authentication - Replay attacks Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 15 Apr 2002 05:47:05 -0400 Tony/Atkinson, I have a few comments on ISIS Cryptographic Authentication mechanism in the context of Replay Attacks. Sorry for the inconvenience if it was already discussed. Though the Draft says "This mechanism does not prevent replay attacks, however such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information.", My interpretation is that we do not have any mechanism protecting from replay attacks of LSP-Sequence-0, Hellos, CSNPs and PSNPs". Here is the description. 1) LSP with Sequence Number 0 ============================= ISO 10589 specifies that we use this special LSP to request the latest LSP from the intended recipient. It can be replayed as many times as the intruder wants. The generation/processing of that LSP may not be triggered by this attack...But I believe the real threat is "Intruder can capture all the LSP-Sequence-0 packets and can replay again and again to consume the resources." The lack of Key-ID mechanism even worsens the situation because a cryptographic LSP-Sequence-0 packet may not be changed very often. 2) CSNPs, PSNPs replay ======================== The worst situation in this case is when intruder replays a particular xSNP packet which could cause a huge transmittals of LSPs. One can replay the same packet repeatedly to consume the maximum resources and perhaps network will never seem to stabilize. 3) Hello PDUs replay-back ========================= As Jerome Etienne points out in "OSPFv2 authentication flaws" Internet Draft, Hello PDUs can be replayed back by MAC address spoofing(Please correct me if MAC address spoofing is not possible) to break the adjacency. Please correct me if I wrongly interpreted anything. Thanks Nagi. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 15 11:00:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19816 for ; Mon, 15 Apr 2002 11:00:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3FEjht55794; Mon, 15 Apr 2002 07:45:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3FEgit55771 for ; Mon, 15 Apr 2002 07:42:44 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3FEt9n47015 for ; Mon, 15 Apr 2002 07:55:09 -0700 (PDT) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 07:48:20 -0700 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3FEoWaD009767; Mon, 15 Apr 2002 10:50:33 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-489.cisco.com [10.82.241.233]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABF10368; Mon, 15 Apr 2002 10:50:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20020415102503.03468a70@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jonnala, Nagi" From: Jeff Learman Subject: Re: [Isis-wg] ISIS Cryptographic Authentication - Replay attacks Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 15 Apr 2002 14:48:20.0717 (UTC) FILETIME=[960E79D0:01C1E48C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 15 Apr 2002 10:50:04 -0400 Very interesting. The "good news" about these flaws is that they can be mounted only by a directly connected system, and the attacked system would act as a firewall protecting the rest of the network, making them much less serious than an LSP replay attack. Regards, Jeff At 05:47 AM 4/15/2002, Jonnala, Nagi wrote: >Tony/Atkinson, > >I have a few comments on ISIS Cryptographic Authentication mechanism >in the context of Replay Attacks. Sorry for the inconvenience if it was >already discussed. > >Though the Draft says "This mechanism does not prevent replay attacks, >however such attacks would trigger existing mechanisms in the IS-IS protocol >that would effectively reject old information.", My interpretation is that >we >do not have any mechanism protecting from replay attacks of LSP-Sequence-0, >Hellos, CSNPs and PSNPs". > >Here is the description. > >1) LSP with Sequence Number 0 >============================= > >ISO 10589 specifies that we use this special LSP to request the latest LSP >from the intended recipient. It can be replayed as many times as the >intruder wants. The generation/processing of that LSP may not be triggered >by this attack...But I believe the real threat is "Intruder >can capture all the LSP-Sequence-0 packets and can replay again and again to >consume the resources." The lack of Key-ID mechanism even worsens the >situation because a cryptographic LSP-Sequence-0 packet may not be changed >very often. > >2) CSNPs, PSNPs replay >======================== > >The worst situation in this case is when intruder >replays a particular xSNP packet which could cause a huge >transmittals of LSPs. One can replay the same packet repeatedly >to consume the maximum resources and perhaps network >will never seem to stabilize. > >3) Hello PDUs replay-back >========================= > >As Jerome Etienne points out in "OSPFv2 authentication flaws" Internet >Draft, Hello PDUs >can be replayed back by MAC address spoofing(Please correct me if MAC >address spoofing is not possible) to break the adjacency. > >Please correct me if I wrongly interpreted anything. > >Thanks >Nagi. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 04:09:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26150 for ; Tue, 16 Apr 2002 04:09:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3G7r0t60102; Tue, 16 Apr 2002 00:53:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3G7qet60090 for ; Tue, 16 Apr 2002 00:52:40 -0700 (PDT) (envelope-from tli@procket.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3G859n67914 for ; Tue, 16 Apr 2002 01:05:09 -0700 (PDT) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Apr 2002 01:03:07 -0700 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id 36DB934432; Tue, 16 Apr 2002 01:09:24 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g3G84wvM016222; Tue, 16 Apr 2002 01:04:58 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g3G84wNp027851; Tue, 16 Apr 2002 01:04:58 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15547.56101.494738.631523@alpha-tli.procket.com> To: "Jonnala, Nagi" Cc: "'tli@procket.net'" , "'rja@extremenetworks.com'" , "'isis-wg@juniper.net'" Subject: [Isis-wg] ISIS Cryptographic Authentication - Replay attacks In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 16 Apr 2002 08:03:08.0124 (UTC) FILETIME=[2508F1C0:01C1E51D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 01:04:53 -0700 Content-Transfer-Encoding: 7bit | Though the Draft says "This mechanism does not prevent replay attacks, | however such attacks would trigger existing mechanisms in the IS-IS protocol | that would effectively reject old information.", My interpretation is that | we | do not have any mechanism protecting from replay attacks of LSP-Sequence-0, | Hellos, CSNPs and PSNPs". Mebbe we need to make the wording stronger here. It was not our intent to claim that we are protected against such attacks. Just that the protocol mechanisms will cause such attacks to be transient. As such, and given the fact that you can DoS anything to death with enough bandwidth and a big enough gun, replay prevention seems low on the list of things to fix. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 09:19:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01832 for ; Tue, 16 Apr 2002 09:19:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GD31t62006; Tue, 16 Apr 2002 06:03:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GD2dt61994 for ; Tue, 16 Apr 2002 06:02:39 -0700 (PDT) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id GAA12642; Tue, 16 Apr 2002 06:15:00 -0700 (PDT) From: "Matthew Noble" To: "Mike Shand (E-mail)" Cc: "'Isis-Wg (E-mail)" Message-ID: <000001c1e549$1049f460$8fdb14ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] receipt of CSNP's during restart Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 14:16:59 +0100 Content-Transfer-Encoding: 7bit Mike An interesting point that I think you may need to highlight in the draft. Say that the restarting node is of type 1/2 and that there are multiple nodes on a given LAN, and that these other nodes on the LAN are of mixed type (levels 1, 2 and 1/2). In this case the restarter will in fact receive 2 sets of complete CSNP's over that (LAN) circuit and the T1 timer for that circuit should not be cancelled until both sets are received (as well as at least one ACK being received). However this does lead to the issue of what to do in this circuitstance when the restarter is type 1/2 but the other nodes on the LAN are only either level 1 _or_ level 2. May be in that case, although the node is type 1/2, the circuit should be congfigured as either type 1 or type 2 as appropriate. In that case the restart knows only to wait for that single CSNP. Any comments? Thanks Matt _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 09:43:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03813 for ; Tue, 16 Apr 2002 09:43:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GDSht62150; Tue, 16 Apr 2002 06:28:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GDP5t62130 for ; Tue, 16 Apr 2002 06:25:05 -0700 (PDT) (envelope-from rsrivats@cisco.com) Received: from router.cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3GDbX9D004003; Tue, 16 Apr 2002 06:37:33 -0700 (PDT) From: Radhika Srivatsa To: Matthew Noble cc: "Mike Shand (E-mail)" , "'Isis-Wg (E-mail)" Subject: Re: [Isis-wg] receipt of CSNP's during restart In-Reply-To: <000001c1e549$1049f460$8fdb14ac@ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 09:37:33 -0400 (EDT) > An interesting point that I think you may need to highlight in the draft. > > Say that the restarting node is of type 1/2 and that there are multiple > nodes on a given LAN, and that these other nodes on the LAN are of mixed > type (levels 1, 2 and 1/2). In this case the restarter will in fact receive > 2 sets of complete CSNP's over that (LAN) circuit and the T1 timer for that > circuit should not be cancelled until both sets are received (as well as at > least one ACK being received). > > However this does lead to the issue of what to do in this circuitstance when > the restarter is type 1/2 but the other nodes on the LAN are only either > level 1 _or_ level 2. May be in that case, although the node is type 1/2, > the circuit should be congfigured as either type 1 or type 2 as appropriate. Are you saying here that we should take care of the circuit-type during the configuration phase itself ? If so, what happens when the topology changes and then the interface would have to receive multi-level CSNPs ? thanks -radhika _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 09:50:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04145 for ; Tue, 16 Apr 2002 09:50:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GDZht62211; Tue, 16 Apr 2002 06:35:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GDUtt62165 for ; Tue, 16 Apr 2002 06:30:55 -0700 (PDT) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id GAA14567; Tue, 16 Apr 2002 06:43:13 -0700 (PDT) From: "Matthew Noble" To: "'Radhika Srivatsa'" , "Matthew Noble" Cc: "Mike Shand (E-mail)" , "'Isis-Wg (E-mail)" Subject: RE: [Isis-wg] receipt of CSNP's during restart Message-ID: <000101c1e54d$011fac60$8fdb14ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 14:45:21 +0100 Content-Transfer-Encoding: 7bit Yes that would be a problem - I only suggested setting the level so that if there were only one type out there on the LAN the restarter wouldn't have to go through the wait/retry cycles unneccesarily for a set of CNSP's that were never coming. Possibly another way is when a node ACK's the restart, it sends the level with the remaining time, so that the restarter can dynamically work out whether or not to wait for one or both sets of CSNP's. Thanks Matt > -----Original Message----- > From: Radhika Srivatsa [mailto:rsrivats@cisco.com] > Sent: Tuesday, April 16, 2002 2:38 PM > To: Matthew Noble > Cc: Mike Shand (E-mail); 'Isis-Wg (E-mail) > Subject: Re: [Isis-wg] receipt of CSNP's during restart > > > > An interesting point that I think you may need to highlight > in the draft. > > > > Say that the restarting node is of type 1/2 and that there > are multiple > > nodes on a given LAN, and that these other nodes on the LAN > are of mixed > > type (levels 1, 2 and 1/2). In this case the restarter will > in fact receive > > 2 sets of complete CSNP's over that (LAN) circuit and the > T1 timer for that > > circuit should not be cancelled until both sets are > received (as well as at > > least one ACK being received). > > > > However this does lead to the issue of what to do in this > circuitstance when > > the restarter is type 1/2 but the other nodes on the LAN > are only either > > level 1 _or_ level 2. May be in that case, although the > node is type 1/2, > > the circuit should be congfigured as either type 1 or type > 2 as appropriate. > > Are you saying here that we should take care of the circuit-type > during the configuration phase itself ? If so, what happens when the > topology changes and then the interface would have to receive > multi-level > CSNPs ? > > thanks > > -radhika > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 15:50:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10317 for ; Tue, 16 Apr 2002 15:50:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GJZ1t63945; Tue, 16 Apr 2002 12:35:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GJYot63930 for ; Tue, 16 Apr 2002 12:34:50 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id <200X3XGG>; Tue, 16 Apr 2002 15:47:19 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DAA@entmail.gnilink.com> From: "Martin, Christian" To: "'isis-wg@external.juniper.net'" Cc: "'stefano previdi'" , Tony Li , "'Tony Przygienda'" , Hannes Gredler , naiming@redback.com, bneal@broadwing.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt - additions and c orrections Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 15:47:13 -0400 Ok, here are the incorporated changes. One issue I have to address and (hopefully) get comments on is the SubTLV changing/deletion issue. Originally, we had specified the possibility of an IS deleting or reordering a (set) of SubTLV(s). My concern after thinking on it is that this isn't possible without causing the LSP to be invalidated because of the new checksum. Before I submit, I'd like to get comments on this. I have included verbage in section 6 that states this, however, I have also included the possibility of changing the subTLVs in section 7. I am thinking we should NOT allow the SubTLV contents to be altered except at L2/L1 boundaries, where new LSPs are originated. Thoughts? Regards, chris Network Working Group Christian Martin INTERNET DRAFT Verzion Global Networks, Inc. Brad Neal Broadwing Communications Stefano Previdi April 2002 Cisco Systems A Policy Control Mechanism is IS-IS Using Administrative Tags 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. The IS- IS protocol is specified in [1], with extensions for supporting IPv4 specified in [2] and further enhancements for Traffic Engineering [4] in [3] and [6]. This document enhances the IS-IS protocol by extending the information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs) as specified in [2]. This Martin, Neal, Previdi [Page 1] INTERNET DRAFT April 2002 extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it is used in the currently defined TLVs. 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 4. Introduction As defined in [2] and extended in [3], the IS-IS protocol may be used to distribute IP prefix reachibility information throughout an IS-IS domain. The IP prefix information is encoded as TLV type 128 and 130 in [2], with additional information carried in TLV 135 as specified in [3] and TLV 235 as defined in [6]. In particular, the extended IP Reachabilty TLV (135) contains support for a larger metric space, an up/down bit to indicate redistribution between different levels in the hierarchy, an IP prefix, and one or more sub-TLVs that can be used to carry specific information about the prefix. TLV 235 is a derivative of TLV 135, with the addition of MultiTopology membership information [6]. As of this writing no sub-TLVs have been defined; however, this draft proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used to carry administrative information about an IP prefix. 5. Sub-TLV Additions This draft proposes 2 new "Administrative Tag" sub-TLVs to be added to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 bit unsigned integers that may be associated with an IP prefix. Example uses of these tags include controlling redistribution between levels and areas, different routing protocols, or multiple instances of IS-IS running on the same router, or carrying BGP standard or extended communites. The methods for which their use is employed is beyond the scope of this document and left to the implementer and/or operator. The encoding of the sub-TLV(s) is discussed in the following Martin, Neal, Previdi [Page 2] INTERNET DRAFT April 2002 subsections. 5.1. 32-bit Administrative Tag Sub-TLV 1 The Administrative Tag shall be encoded as one or more 4 octet unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The Administrative Tag Sub-TLV has following structure: 1 octet of type (value: 1) 1 octet of length (value: multiple of 4) one or more instances of 4 octets of administrative tag An implementation may consider only one of the encoded tags, in which case the first encoded tag must be considered. A tag value of zero is reserved and should be treated as "no tag". 5.2. 64-bit Administrative Tag Sub-TLV 2 The Administrative Tag shall be encoded as one or more 8 octet unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The 64-bit Administrative Tag Sub-TLV has following structure: 1 octet of type (value: 1) 1 octet of length (value: multiple of 8) one or more instances of 8 octets of administrative tag An implementation may consider only one of the encoded tags, in which case the first encoded tag must be considered. A tag value of zero is reserved and should be treated as "no tag". 6. Ordering of Tags The ordering of tags is implied. That is, tags set by an LSP originator should be flooded throughout the IS-IS domain unchanged. Each IS that receives an LSP with TLV 135 or TLV 235, that have additional SubTLV 1 and/or 2 MAY operate on the tag values as warranted by the implementation. Tag values SHOULD NOT be deleted or changed within an area. If an implementation needs to change tag values, for example, at an area boundary, then the TLV(s) SHOULD be copied to the IS Level-2 LSP at which point, the contents of the SubTLV(s) MAY change. Martin, Neal, Previdi [Page 3] INTERNET DRAFT April 2002 7. A compliant IS-IS implementation: MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or 235. MAY be able to assign more than one tag to any IP prefix in TLV(s) 135 and/or 235. MAY be able to rewrite or remove one or more tags associated with a prefix in TLV 135. 8. Operation An administrator associates an Administrative Tag value with some interesting property. When IS-IS advertises reachability for some IP prefix that has that property, it adds the Administrative Tag to the IP reachability information TLV for that prefix, and the tag "sticks" to the prefix as it is flooded throughout the routing domian. Consider the network in figure 1. We wish to "leak" L1 prefixes [5] with some property, A, from L2 to the L1 router R1. Without policy- groups, there is no way for R2 to know property A prefixes from property B prefixes. R2--------R3--------R4 L2 / \ - - - /- - - - - - - - - - - - - - L1 / \ R1 R5----1.1.1.0/24 (A) | | 1.1.2.0/24 (B) Figure 1 We associate Administrative Tag 100 with property A, and have R5 attach that value to the IP extended reachability information TLV for prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with Administrative Tag 100, and leak to L1." The previous example is rather simplistic; it seems that it would be just as easy for R2 simply to match the prefix 1.1.1.0/24. However, if there are a large number of routers that need to apply some policy according to property A and large number of "A" prefixes, this Martin, Neal, Previdi [Page 4] INTERNET DRAFT April 2002 mechanism can be quite helpful. 9. Security Considerations This document raises no new security issues for IS-IS, as any annotations to IP prefixes should not pass outside the administrative control of the network operator of the IS-IS domain. Such an allowance would violate the spirit of Interior Gateway Protocols in general and IS-IS in particular. 10. IANA Considerations The authors have chosen "1" as the typecode of the 32-bit Administrative Tag sub-TLV and "2" as the typecode of the 64-bt Administrative Tag SubTLV. These must be allocated by IANA. 11. Acknowledgments The authors would like to thank Henk Smit for clarifying the best place to describe this new information, Tony Li and Tony Przygienda for useful comments on this draft, Danny McPherson for some much needed formatting assistance, and Mike Shand for useful discussions on encoding structure of the sub-TLV. 12. References [1] "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)", ISO 10589. [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", Internet Draft, "Work in Progress", September 2000. [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999. [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution with Two-Level IS-IS" RFC 2966, October 2000 Martin, Neal, Previdi [Page 5] INTERNET DRAFT April 2002 [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 2002. 13. Authors' Address Christian Martin Verizon Global Networks, Inc. 1880 Campus Commons Dr Reston, VA 20191 Email: cmartin@verizongni.com Voice: 1 (703) 2954394 Fax: 1 (703) 2954279 Brad Neal Broadwing Communications 1835 Kramer Lane - Suite 100 Austin, TX 78758 USA Email: bneal@broadwing.com Voice: 1 (512) 7421310 Fax: 1 (512) 7421333 Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium email: sprevidi@cisco.com Martin, Neal, Previdi [Page 6] _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 16:47:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17272 for ; Tue, 16 Apr 2002 16:47:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GKVht64249; Tue, 16 Apr 2002 13:31:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GKRTt64223 for ; Tue, 16 Apr 2002 13:27:29 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 4E2B74BA214; Tue, 16 Apr 2002 13:40:02 -0700 (PDT) To: "Martin, Christian" Cc: "'isis-wg@external.juniper.net'" , "'stefano previdi'" , Tony Li , "'Tony Przygienda'" , Hannes Gredler , bneal@broadwing.com In-reply-to: Mail from "Martin, Christian" dated Tue, 16 Apr 2002 15:47:13 EDT <94B9091E1149D411A45C00508BACEB35015F2DAA@entmail.gnilink.com> From: Naiming Shen Message-Id: <20020416204002.4E2B74BA214@prattle.redback.com> Subject: [Isis-wg] Re: draft-martin-neal-policy-isis-admin-tags-05.txt - additions and c orrections Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 13:40:02 -0700 we don't have the right to touch(alter) someone else's packet. in the leaking case, we form our new packets, so we can do whatever we want. thanks. ] Ok, here are the incorporated changes. One issue I have to address and ] (hopefully) get comments on is the SubTLV changing/deletion issue. ] Originally, we had specified the possibility of an IS deleting or reordering ] a (set) of SubTLV(s). My concern after thinking on it is that this isn't ] possible without causing the LSP to be invalidated because of the new ] checksum. Before I submit, I'd like to get comments on this. I have ] included verbage in section 6 that states this, however, I have also ] included the possibility of changing the subTLVs in section 7. I am ] thinking we should NOT allow the SubTLV contents to be altered except at ] L2/L1 boundaries, where new LSPs are originated. Thoughts? ] ] Regards, ] chris ] ] ] ] ] ] Network Working Group Christian Martin ] INTERNET DRAFT Verzion Global Networks, Inc. ] Brad Neal ] Broadwing Communications ] Stefano Previdi ] April 2002 Cisco Systems ] ] ] ] A Policy Control Mechanism is IS-IS Using Administrative Tags ] ] ] ] 1. Status of this Memo ] ] This document is an Internet-Draft and is in full conformance with ] all provisions of Section 10 of RFC 2026. ] ] Internet-Drafts are working documents of the Internet Engineering ] Task Force (IETF), its areas, and its working groups. Note that ] other groups may also distribute working documents as Internet- ] Drafts. ] ] Internet-Drafts are draft documents valid for a maximum of six months ] and may be updated, replaced, or obsoleted by other documents at any ] time. It is inappropriate to use Internet- Drafts as reference ] material or to cite them other than as "work in progress." ] ] The list of current Internet-Drafts can be accessed at ] http://www.ietf.org/ietf/1id-abstracts.txt ] ] The list of Internet-Draft Shadow Directories can be accessed at ] http://www.ietf.org/shadow.html. ] ] ] 2. Abstract ] ] This document describes an extension to the IS-IS protocol to add ] operational capabilities that allow for ease of management and ] control over IP prefix distribution within an IS-IS domain. The IS- ] IS protocol is specified in [1], with extensions for supporting IPv4 ] specified in [2] and further enhancements for Traffic Engineering [4] ] in [3] and [6]. ] ] This document enhances the IS-IS protocol by extending the ] information that a Intermediate System (IS) [router] can place in ] Link State Protocol Data Units (LSPs) as specified in [2]. This ] ] ] ] Martin, Neal, Previdi [Page 1] ] ] ] ] ] ] ] INTERNET DRAFT April 2002 ] ] ] extension will provide operators with a mechanism to control IP ] prefix distribution throughout multi-level IS-IS domains. ] Additionally, the information can be placed in LSPs that have TLVs as ] yet undefined, if this information is used to convey the same meaning ] in these future TLVs as it is used in the currently defined TLVs. ] ] ] ] 3. Specification of Requirements ] ] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ] "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this ] document are to be interpreted as described in [RFC 2119]. ] ] ] 4. Introduction ] ] As defined in [2] and extended in [3], the IS-IS protocol may be used ] to distribute IP prefix reachibility information throughout an IS-IS ] domain. The IP prefix information is encoded as TLV type 128 and 130 ] in [2], with additional information carried in TLV 135 as specified ] in [3] and TLV 235 as defined in [6]. In particular, the extended IP ] Reachabilty TLV (135) contains support for a larger metric space, an ] up/down bit to indicate redistribution between different levels in ] the hierarchy, an IP prefix, and one or more sub-TLVs that can be ] used to carry specific information about the prefix. TLV 235 is a ] derivative of TLV 135, with the addition of MultiTopology membership ] information [6]. ] ] As of this writing no sub-TLVs have been defined; however, this draft ] proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used ] to carry administrative information about an IP prefix. ] ] ] 5. Sub-TLV Additions ] ] This draft proposes 2 new "Administrative Tag" sub-TLVs to be added ] to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 ] bit unsigned integers that may be associated with an IP prefix. ] Example uses of these tags include controlling redistribution between ] levels and areas, different routing protocols, or multiple instances ] of IS-IS running on the same router, or carrying BGP standard or ] extended communites. ] ] The methods for which their use is employed is beyond the scope of ] this document and left to the implementer and/or operator. ] ] The encoding of the sub-TLV(s) is discussed in the following ] ] ] ] Martin, Neal, Previdi [Page 2] ] ] ] ] ] ] ] INTERNET DRAFT April 2002 ] ] ] subsections. ] ] ] 5.1. 32-bit Administrative Tag Sub-TLV 1 ] ] The Administrative Tag shall be encoded as one or more 4 octet ] unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The ] Administrative Tag Sub-TLV has following structure: ] ] 1 octet of type (value: 1) ] 1 octet of length (value: multiple of 4) ] one or more instances of 4 octets of administrative tag ] ] An implementation may consider only one of the encoded tags, in which ] case the first encoded tag must be considered. A tag value of zero ] is reserved and should be treated as "no tag". ] ] ] 5.2. 64-bit Administrative Tag Sub-TLV 2 ] ] The Administrative Tag shall be encoded as one or more 8 octet ] unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The ] 64-bit Administrative Tag Sub-TLV has following structure: ] ] 1 octet of type (value: 1) ] 1 octet of length (value: multiple of 8) ] one or more instances of 8 octets of administrative tag ] ] An implementation may consider only one of the encoded tags, in which ] case the first encoded tag must be considered. A tag value of zero ] is reserved and should be treated as "no tag". ] ] ] 6. Ordering of Tags ] ] The ordering of tags is implied. That is, tags set by an LSP ] originator should be flooded throughout the IS-IS domain unchanged. ] Each IS that receives an LSP with TLV 135 or TLV 235, that have ] additional SubTLV 1 and/or 2 MAY operate on the tag values as ] warranted by the implementation. Tag values SHOULD NOT be deleted or ] changed within an area. If an implementation needs to change tag values, ] ] for example, at an area boundary, then the TLV(s) SHOULD be copied to the ] IS Level-2 LSP at which point, the contents of the SubTLV(s) MAY ] change. ] ] ] ] ] ] ] ] Martin, Neal, Previdi [Page 3] ] ] ] ] ] ] ] INTERNET DRAFT April 2002 ] ] ] 7. A compliant IS-IS implementation: ] ] MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or ] 235. ] ] MAY be able to assign more than one tag to any IP prefix in TLV(s) ] 135 and/or 235. ] ] MAY be able to rewrite or remove one or more tags associated with a ] prefix in TLV 135. ] ] ] 8. Operation ] ] An administrator associates an Administrative Tag value with some ] interesting property. When IS-IS advertises reachability for some IP ] prefix that has that property, it adds the Administrative Tag to the ] IP reachability information TLV for that prefix, and the tag "sticks" ] to the prefix as it is flooded throughout the routing domian. ] ] Consider the network in figure 1. We wish to "leak" L1 prefixes [5] ] with some property, A, from L2 to the L1 router R1. Without policy- ] groups, there is no way for R2 to know property A prefixes from ] property B prefixes. ] ] ] ] R2--------R3--------R4 ] L2 / \ ] - - - /- - - - - - - - - - - - - - ] L1 / \ ] R1 R5----1.1.1.0/24 (A) ] | ] | ] 1.1.2.0/24 (B) ] ] ] Figure 1 ] ] We associate Administrative Tag 100 with property A, and have R5 ] attach that value to the IP extended reachability information TLV for ] prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with ] Administrative Tag 100, and leak to L1." ] ] The previous example is rather simplistic; it seems that it would be ] just as easy for R2 simply to match the prefix 1.1.1.0/24. However, ] if there are a large number of routers that need to apply some policy ] according to property A and large number of "A" prefixes, this ] ] ] ] Martin, Neal, Previdi [Page 4] ] ] ] ] ] ] ] INTERNET DRAFT April 2002 ] ] ] mechanism can be quite helpful. ] ] ] ] 9. Security Considerations ] ] This document raises no new security issues for IS-IS, as any ] annotations to IP prefixes should not pass outside the administrative ] control of the network operator of the IS-IS domain. Such an ] allowance would violate the spirit of Interior Gateway Protocols in ] general and IS-IS in particular. ] ] ] 10. IANA Considerations ] ] The authors have chosen "1" as the typecode of the 32-bit ] Administrative Tag sub-TLV and "2" as the typecode of the 64-bt ] Administrative Tag SubTLV. These must be allocated by IANA. ] ] ] 11. Acknowledgments ] ] The authors would like to thank Henk Smit for clarifying the best ] place to describe this new information, Tony Li and Tony Przygienda ] for useful comments on this draft, Danny McPherson for some much ] needed formatting assistance, and Mike Shand for useful discussions ] on encoding structure of the sub-TLV. ] ] ] 12. References ] ] [1] "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)", ] ISO 10589. ] ] [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and ] dual environments", RFC 1195, December 1990. ] ] [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", ] Internet Draft, "Work in Progress", September 2000. ] ] [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, ] J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, ] September 1999. ] ] [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution ] with Two-Level IS-IS" RFC 2966, October 2000 ] ] ] ] Martin, Neal, Previdi [Page 5] ] ] ] ] ] ] ] INTERNET DRAFT April 2002 ] ] ] [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology ] Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, ] April 2002. ] ] ] ] 13. Authors' Address ] ] Christian Martin ] Verizon Global Networks, Inc. ] 1880 Campus Commons Dr ] Reston, VA 20191 ] Email: cmartin@verizongni.com ] Voice: 1 (703) 2954394 ] Fax: 1 (703) 2954279 ] ] Brad Neal ] Broadwing Communications ] 1835 Kramer Lane - Suite 100 ] Austin, TX 78758 ] USA ] Email: bneal@broadwing.com ] Voice: 1 (512) 7421310 ] Fax: 1 (512) 7421333 ] ] Stefano Previdi ] Cisco Systems, Inc. ] De Kleetlaan 6A ] 1831 Diegem - Belgium ] email: sprevidi@cisco.com ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] Martin, Neal, Previdi [Page 6] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 16 17:51:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24717 for ; Tue, 16 Apr 2002 17:51:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GLaPt64599; Tue, 16 Apr 2002 14:36:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3GLQJt64547 for ; Tue, 16 Apr 2002 14:26:19 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id <200X3XT9>; Tue, 16 Apr 2002 17:38:52 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DAD@entmail.gnilink.com> From: "Martin, Christian" To: "'Naiming Shen'" , "Martin, Christian" Cc: "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] RE: draft-martin-neal-policy-isis-admin-tags-05.txt - additions a nd c orrections Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 17:38:41 -0400 Naiming, Agreed. I wanted to make sure this was explicit. Changing TLV contents is not allowed, except at are borders when creating new LSPs. I shall incorporate the language and resend to the group. If there are no objections, I will submit to the rfc-editor. chris >-----Original Message----- >From: Naiming Shen [mailto:naiming@redback.com] >Sent: Tuesday, April 16, 2002 4:40 PM >To: Martin, Christian >Cc: 'isis-wg@external.juniper.net'; 'stefano previdi'; Tony >Li; 'Tony Przygienda'; Hannes Gredler; bneal@broadwing.com >Subject: Re: draft-martin-neal-policy-isis-admin-tags-05.txt - >additions and c orrections > > > >we don't have the right to touch(alter) someone else's packet. >in the leaking case, we form our new packets, so we can do >whatever we want. > >thanks. > > ] Ok, here are the incorporated changes. One issue I have to >address and ] (hopefully) get comments on is the SubTLV >changing/deletion issue. ] Originally, we had specified the >possibility of an IS deleting or reordering ] a (set) of >SubTLV(s). My concern after thinking on it is that this isn't > ] possible without causing the LSP to be invalidated because >of the new ] checksum. Before I submit, I'd like to get >comments on this. I have ] included verbage in section 6 >that states this, however, I have also ] included the >possibility of changing the subTLVs in section 7. I am ] >thinking we should NOT allow the SubTLV contents to be altered >except at ] L2/L1 boundaries, where new LSPs are originated. >Thoughts? ] > ] Regards, > ] chris > ] > ] > ] > ] > ] > ] Network Working Group >Christian Martin > ] INTERNET DRAFT Verzion Global >Networks, Inc. > ] > Brad Neal > ] Broadwing >Communications > ] >Stefano Previdi > ] April 2002 >Cisco Systems > ] > ] > ] > ] A Policy Control Mechanism is IS-IS Using Administrative Tags > ] > ] > ] > ] 1. Status of this Memo > ] > ] This document is an Internet-Draft and is in full >conformance with > ] all provisions of Section 10 of RFC 2026. > ] > ] Internet-Drafts are working documents of the Internet Engineering > ] Task Force (IETF), its areas, and its working groups. Note that > ] other groups may also distribute working documents as Internet- > ] Drafts. > ] > ] Internet-Drafts are draft documents valid for a maximum >of six months > ] and may be updated, replaced, or obsoleted by other >documents at any > ] time. It is inappropriate to use Internet- Drafts as reference > ] material or to cite them other than as "work in progress." > ] > ] The list of current Internet-Drafts can be accessed at > ] http://www.ietf.org/ietf/1id-abstracts.txt > ] > ] The list of Internet-Draft Shadow Directories can be accessed at > ] http://www.ietf.org/shadow.html. > ] > ] > ] 2. Abstract > ] > ] This document describes an extension to the IS-IS protocol to add > ] operational capabilities that allow for ease of management and > ] control over IP prefix distribution within an IS-IS >domain. The IS- > ] IS protocol is specified in [1], with extensions for >supporting IPv4 > ] specified in [2] and further enhancements for Traffic >Engineering [4] > ] in [3] and [6]. > ] > ] This document enhances the IS-IS protocol by extending the > ] information that a Intermediate System (IS) [router] can place in > ] Link State Protocol Data Units (LSPs) as specified in [2]. This > ] > ] > ] > ] Martin, Neal, Previdi [Page 1] > ] > ] > ] > ] > ] > ] > ] INTERNET DRAFT > April 2002 > ] > ] > ] extension will provide operators with a mechanism to control IP > ] prefix distribution throughout multi-level IS-IS domains. > ] Additionally, the information can be placed in LSPs that >have TLVs as > ] yet undefined, if this information is used to convey the >same meaning > ] in these future TLVs as it is used in the currently defined TLVs. > ] > ] > ] > ] 3. Specification of Requirements > ] > ] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >"SHALL NOT", > ] "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >"OPTIONAL" in this > ] document are to be interpreted as described in [RFC 2119]. > ] > ] > ] 4. Introduction > ] > ] As defined in [2] and extended in [3], the IS-IS >protocol may be used > ] to distribute IP prefix reachibility information >throughout an IS-IS > ] domain. The IP prefix information is encoded as TLV >type 128 and 130 > ] in [2], with additional information carried in TLV 135 >as specified > ] in [3] and TLV 235 as defined in [6]. In particular, >the extended IP > ] Reachabilty TLV (135) contains support for a larger >metric space, an > ] up/down bit to indicate redistribution between different >levels in > ] the hierarchy, an IP prefix, and one or more sub-TLVs that can be > ] used to carry specific information about the prefix. >TLV 235 is a > ] derivative of TLV 135, with the addition of >MultiTopology membership > ] information [6]. > ] > ] As of this writing no sub-TLVs have been defined; >however, this draft > ] proposes 2 new sub-TLVs for both TLV 135 and TLV 235 >that may be used > ] to carry administrative information about an IP prefix. > ] > ] > ] 5. Sub-TLV Additions > ] > ] This draft proposes 2 new "Administrative Tag" sub-TLVs >to be added > ] to TLV 135 and 235. These TLVs specify one or more >ordered, 32 or 64 > ] bit unsigned integers that may be associated with an IP prefix. > ] Example uses of these tags include controlling >redistribution between > ] levels and areas, different routing protocols, or >multiple instances > ] of IS-IS running on the same router, or carrying BGP standard or > ] extended communites. > ] > ] The methods for which their use is employed is beyond >the scope of > ] this document and left to the implementer and/or operator. > ] > ] The encoding of the sub-TLV(s) is discussed in the following > ] > ] > ] > ] Martin, Neal, Previdi [Page 2] > ] > ] > ] > ] > ] > ] > ] INTERNET DRAFT > April 2002 > ] > ] > ] subsections. > ] > ] > ] 5.1. 32-bit Administrative Tag Sub-TLV 1 > ] > ] The Administrative Tag shall be encoded as one or more 4 octet > ] unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV >235 [6]. The > ] Administrative Tag Sub-TLV has following structure: > ] > ] 1 octet of type (value: 1) > ] 1 octet of length (value: multiple of 4) > ] one or more instances of 4 octets of administrative tag > ] > ] An implementation may consider only one of the encoded >tags, in which > ] case the first encoded tag must be considered. A tag >value of zero > ] is reserved and should be treated as "no tag". > ] > ] > ] 5.2. 64-bit Administrative Tag Sub-TLV 2 > ] > ] The Administrative Tag shall be encoded as one or more 8 octet > ] unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV >235 [6]. The > ] 64-bit Administrative Tag Sub-TLV has following structure: > ] > ] 1 octet of type (value: 1) > ] 1 octet of length (value: multiple of 8) > ] one or more instances of 8 octets of administrative tag > ] > ] An implementation may consider only one of the encoded >tags, in which > ] case the first encoded tag must be considered. A tag >value of zero > ] is reserved and should be treated as "no tag". > ] > ] > ] 6. Ordering of Tags > ] > ] The ordering of tags is implied. That is, tags set by an LSP > ] originator should be flooded throughout the IS-IS domain >unchanged. > ] Each IS that receives an LSP with TLV 135 or TLV 235, that have > ] additional SubTLV 1 and/or 2 MAY operate on the tag values as > ] warranted by the implementation. Tag values SHOULD NOT >be deleted or > ] changed within an area. If an implementation needs to >change tag values, > ] > ] for example, at an area boundary, then the TLV(s) SHOULD >be copied to the > ] IS Level-2 LSP at which point, the contents of the SubTLV(s) MAY > ] change. > ] > ] > ] > ] > ] > ] > ] > ] Martin, Neal, Previdi [Page 3] > ] > ] > ] > ] > ] > ] > ] INTERNET DRAFT > April 2002 > ] > ] > ] 7. A compliant IS-IS implementation: > ] > ] MUST be able to assign one tag to any IP prefix in >TLV(s) 135 and/or > ] 235. > ] > ] MAY be able to assign more than one tag to any IP prefix >in TLV(s) > ] 135 and/or 235. > ] > ] MAY be able to rewrite or remove one or more tags >associated with a > ] prefix in TLV 135. > ] > ] > ] 8. Operation > ] > ] An administrator associates an Administrative Tag value with some > ] interesting property. When IS-IS advertises >reachability for some IP > ] prefix that has that property, it adds the >Administrative Tag to the > ] IP reachability information TLV for that prefix, and the >tag "sticks" > ] to the prefix as it is flooded throughout the routing domian. > ] > ] Consider the network in figure 1. We wish to "leak" L1 >prefixes [5] > ] with some property, A, from L2 to the L1 router R1. >Without policy- > ] groups, there is no way for R2 to know property A prefixes from > ] property B prefixes. > ] > ] > ] > ] R2--------R3--------R4 > ] L2 / \ > ] - - - /- - - - - - - - - - - - - - > ] L1 / \ > ] R1 R5----1.1.1.0/24 (A) > ] | > ] | > ] 1.1.2.0/24 (B) > ] > ] > ] Figure 1 > ] > ] We associate Administrative Tag 100 with property A, and have R5 > ] attach that value to the IP extended reachability >information TLV for > ] prefix 1.1.1.0/24. R2 has a policy in place to "match >prefixes with > ] Administrative Tag 100, and leak to L1." > ] > ] The previous example is rather simplistic; it seems that >it would be > ] just as easy for R2 simply to match the prefix >1.1.1.0/24. However, > ] if there are a large number of routers that need to >apply some policy > ] according to property A and large number of "A" prefixes, this > ] > ] > ] > ] Martin, Neal, Previdi [Page 4] > ] > ] > ] > ] > ] > ] > ] INTERNET DRAFT > April 2002 > ] > ] > ] mechanism can be quite helpful. > ] > ] > ] > ] 9. Security Considerations > ] > ] This document raises no new security issues for IS-IS, as any > ] annotations to IP prefixes should not pass outside the >administrative > ] control of the network operator of the IS-IS domain. Such an > ] allowance would violate the spirit of Interior Gateway >Protocols in > ] general and IS-IS in particular. > ] > ] > ] 10. IANA Considerations > ] > ] The authors have chosen "1" as the typecode of the 32-bit > ] Administrative Tag sub-TLV and "2" as the typecode of the 64-bt > ] Administrative Tag SubTLV. These must be allocated by IANA. > ] > ] > ] 11. Acknowledgments > ] > ] The authors would like to thank Henk Smit for clarifying the best > ] place to describe this new information, Tony Li and Tony >Przygienda > ] for useful comments on this draft, Danny McPherson for some much > ] needed formatting assistance, and Mike Shand for useful >discussions > ] on encoding structure of the sub-TLV. > ] > ] > ] 12. References > ] > ] [1] "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)", > ] ISO 10589. > ] > ] [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing >in TCP/IP and > ] dual environments", RFC 1195, December 1990. > ] > ] [3] Li, T., and Smit, H., "IS-IS extensions for Traffic >Engineering", > ] Internet Draft, "Work in Progress", September 2000. > ] > ] [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. >and McManus, > ] J., "Requirements for Traffic Engineering Over >MPLS," RFC 2702, > ] September 1999. > ] > ] [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix >Distribution > ] with Two-Level IS-IS" RFC 2966, October 2000 > ] > ] > ] > ] Martin, Neal, Previdi [Page 5] > ] > ] > ] > ] > ] > ] > ] INTERNET DRAFT > April 2002 > ] > ] > ] [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology > ] Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, > ] April 2002. > ] > ] > ] > ] 13. Authors' Address > ] > ] Christian Martin > ] Verizon Global Networks, Inc. > ] 1880 Campus Commons Dr > ] Reston, VA 20191 > ] Email: cmartin@verizongni.com > ] Voice: 1 (703) 2954394 > ] Fax: 1 (703) 2954279 > ] > ] Brad Neal > ] Broadwing Communications > ] 1835 Kramer Lane - Suite 100 > ] Austin, TX 78758 > ] USA > ] Email: bneal@broadwing.com > ] Voice: 1 (512) 7421310 > ] Fax: 1 (512) 7421333 > ] > ] Stefano Previdi > ] Cisco Systems, Inc. > ] De Kleetlaan 6A > ] 1831 Diegem - Belgium > ] email: sprevidi@cisco.com > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] Martin, Neal, Previdi [Page 6] > >- Naiming > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 00:21:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01616 for ; Wed, 17 Apr 2002 00:21:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3H461t66452; Tue, 16 Apr 2002 21:06:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3H45ht66440 for ; Tue, 16 Apr 2002 21:05:43 -0700 (PDT) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.52.229]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GUP00FYP2MHB0@mta7.pltn13.pbi.net> for isis-wg@spider.juniper.net; Tue, 16 Apr 2002 21:18:18 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt - additions and c orrections To: "Martin, Christian" Cc: "'isis-wg@external.juniper.net'" , "'stefano previdi'" , Tony Li , "'Tony Przygienda'" , Hannes Gredler , naiming@redback.com, bneal@broadwing.com Message-id: <3CBD001A.8080408@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <94B9091E1149D411A45C00508BACEB35015F2DAA@entmail.gnilink.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Apr 2002 21:54:50 -0700 Content-Transfer-Encoding: 7BIT Martin, Christian wrote: > >Originally, we had specified the possibility of an IS deleting or reordering >a (set) of SubTLV(s). My concern after thinking on it is that this isn't >possible without causing the LSP to be invalidated because of the new >checksum. Before I submit, I'd like to get comments on this. I have >included verbage in section 6 that states this, however, I have also >included the possibility of changing the subTLVs in section 7. I am >thinking we should NOT allow the SubTLV contents to be altered except at >L2/L1 boundaries, where new LSPs are originated. Thoughts? > yes, you _cannot_ change other people LSPs and if you change yours, you need new version number and checksum anyway. Comment for deletion and I'm getting picky here, you may not want to go into this matter. What you specified is an ordered set or a chain but one could also think of an array, to give you an example, assume I send you version 1 with 3 tags for a route {X,Y,Z}. The next version contains {X,Z}. The interpretation could be either a) the route has a tag X that preceeds tag Z which could e.g. mean that tag X overrides certain properties of tag Z or any such thing. or b) the route had a first tag X, then a second tag Y, then a third tag Z and now it has a firs tag X and a _second_ tag Z. First tag e.g. always encodes an extended community, second is a customer tag, third is tag indicating that route is a summary as example. What does it mean? In a second interpretation, the semantics of {X,Z} and {X,NULL-TAG,Z} are different, in the first interpreation both constructs mean the same. IMO, think what you want to have or say that both are possible and interpretation depends on application. And oh, you misspelled Verizon in the header unless it's a different company ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 09:59:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18034 for ; Wed, 17 Apr 2002 09:59:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HDi1t69302; Wed, 17 Apr 2002 06:44:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HDhmt69290 for ; Wed, 17 Apr 2002 06:43:48 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3HDuQ696771 for ; Wed, 17 Apr 2002 06:56:26 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Apr 2002 06:52:20 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17522; Wed, 17 Apr 2002 09:54:05 -0400 (EDT) Message-Id: <200204171354.JAA17522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 17 Apr 2002 13:52:20.0468 (UTC) FILETIME=[1804AB40:01C1E617] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 09:54:05 -0400 --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 : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-06.txt Pages : 9 Date : 16-Apr-02 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-06.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-3way-06.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: <20020416152252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020416152252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 13:28:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28427 for ; Wed, 17 Apr 2002 13:28:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HHDht70323; Wed, 17 Apr 2002 10:13:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HHAft70303 for ; Wed, 17 Apr 2002 10:10:41 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 13:23:19 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DB5@entmail.gnilink.com> From: "Martin, Christian" To: "'Tony Przygienda'" , "Martin, Christian" Cc: "'isis-wg@external.juniper.net'" , "'stefano previdi'" , Tony Li , "'Tony Przygienda'" , Hannes Gredler , naiming@redback.com, bneal@broadwing.com Subject: RE: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt - a dditions and c orrections MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 13:23:18 -0400 Tony, >> >yes, you _cannot_ change other people LSPs and if you change >yours, you >need new version number and >checksum anyway. Agreed. The tag changes can only occur at area boundaries where TLV 135 is copied into the new area's LSP. > >Comment for deletion and I'm getting picky here, you may not >want to go >into this matter. What you specified >is an ordered set or a chain but one could also think of an array, to >give you an example, assume I send you >version 1 with 3 tags for a route {X,Y,Z}. The next version contains >{X,Z}. The interpretation could be either > >a) the route has a tag X that preceeds tag Z which could e.g. >mean that >tag X overrides certain properties > of tag Z or any such thing. > >or > >b) the route had a first tag X, then a second tag Y, then a >third tag Z >and now it has a > firs tag X and a _second_ tag Z. First tag e.g. always encodes an >extended community, > second is a customer tag, > third is tag indicating that route is a summary as example. > >What does it mean? In a second interpretation, the semantics of {X,Z} >and {X,NULL-TAG,Z} are different, >in the first interpreation both constructs mean the same. > >IMO, think what you want to have or say that both are possible and >interpretation depends on application. Ok, I see the issue. How about this: 6. Ordering of Tags The semantics of the tag order are implementation-dependent. That is, there is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need be performed, based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A preceeds or succeeds tag B SHOULD not change the meaning of the tag set. However, an implementation MAY wish to preserve tag ordering such that an ordered set of tags has meaning to the local policy. Each IS that receives an LSP with TLV(s) 135 and/or 235, that have associated SubTLV(s) 1 and/or 2, MAY operate on the tag values as warranted by the implementation. If an implementation needs to change tag values, for example, at an area boundary, then the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s) MAY change as dictated by the policy action. In the event that no change is required, the SubTLV(s) SHOULD be copied in order into the new LSP, such that ordering is preserved. >And oh, you misspelled Verizon in the header unless it's a different >company ;-) Whoops. Good catch - actually that was an old nroff that I reused - we've reorged since so I was working for a non-existent subsidiary of an non-existent company! ;) Thanks for the suggestions! -chris > > thanks > > -- tony > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 14:09:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29860 for ; Wed, 17 Apr 2002 14:09:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HHtQt70571; Wed, 17 Apr 2002 10:55:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HHkct70506 for ; Wed, 17 Apr 2002 10:46:38 -0700 (PDT) (envelope-from muthu@coronanetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3HHxGn09728 for ; Wed, 17 Apr 2002 10:59:17 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailsrv.coronanetworks.com ([67.104.79.164]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Apr 2002 10:56:09 -0700 Received: by mailsrv.coronanetworks.com with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Apr 2002 10:46:22 -0700 Message-ID: From: Vairamuthu Karuppiah To: isis-wg@juniper.net Subject: RE: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Apr 2002 17:56:09.0859 (UTC) FILETIME=[27D09530:01C1E639] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 10:44:01 -0700 Hi, I would like to know some information on "How to encapsulate the ISIS packets over Ethernet and PPP link". Does anybody know where can I get these information. Cheers K.Vairamuthu -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, April 17, 2002 6:54 AM Cc: isis-wg@juniper.net Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt 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 : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-06.txt Pages : 9 Date : 16-Apr-02 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-06.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-3way-06.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. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 14:20:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00209 for ; Wed, 17 Apr 2002 14:20:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HI5Pt70664; Wed, 17 Apr 2002 11:05:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HHwqt70595 for ; Wed, 17 Apr 2002 10:58:52 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3HIBVT62541; Wed, 17 Apr 2002 11:11:31 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g3HIBVE91898; Wed, 17 Apr 2002 11:11:31 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200204171811.g3HIBVE91898@cirrus.juniper.net> From: Dave Katz To: muthu@coronanetworks.com CC: isis-wg@juniper.net In-reply-to: (message from Vairamuthu Karuppiah on Wed, 17 Apr 2002 10:44:01 -0700) Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 11:11:31 -0700 (PDT) Ethernet encapsulation is specified in the base spec (it's actually 802.3/802.2) PPP encapsulation uses the OSINCP, RFC 1377. I would like to know some information on "How to encapsulate the ISIS packets over Ethernet and PPP link". Does anybody know where can I get these information. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 16:12:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05593 for ; Wed, 17 Apr 2002 16:12:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HJvQt71243; Wed, 17 Apr 2002 12:57:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HJj2t71179 for ; Wed, 17 Apr 2002 12:45:02 -0700 (PDT) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3HJvf605397; Wed, 17 Apr 2002 12:57:41 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Apr 2002 12:55:43 -0700 Received: from redback.com ([63.200.50.217]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GUQ00DL5A40YR@mta6.snfc21.pbi.net>; Wed, 17 Apr 2002 12:57:36 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt To: Dave Katz Cc: muthu@coronanetworks.com, isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CBDB44E.D0C9B90E@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200204171811.g3HIBVE91898@cirrus.juniper.net> X-OriginalArrivalTime: 17 Apr 2002 19:55:43.0999 (UTC) FILETIME=[DBEF78F0:01C1E649] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 10:43:42 -0700 Content-Transfer-Encoding: 7BIT Dave Katz wrote: > Ethernet encapsulation is specified in the base spec (it's actually > 802.3/802.2) PPP encapsulation uses the OSINCP, RFC 1377. > > I would like to know some information on "How to encapsulate the ISIS > packets over Ethernet and PPP link". Does anybody know where can I get these > information. that question is asked all over again by people starting with the protocol. Maybe the isis-update subworkgroup could put out into their document(s) stating that. On top of that encapsulation over ATM is worth documenting (when not running PPP) since I don't remember ever seeing that. There was also the Henk-hack draft that I think expired and maybe worth resurecting in this context since as far I heard one or two people switched it on. Don't know whether it's being still used though. However, the easiest way is to plug an analyzer into any leading vendor and sniff 2-3 frames. Guess that doesn't count as a standard document conform proposal though ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 16:36:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06587 for ; Wed, 17 Apr 2002 16:36:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HKMXt71390; Wed, 17 Apr 2002 13:22:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HJpnt71209 for ; Wed, 17 Apr 2002 12:51:49 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com ([63.200.50.217]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GUQ001A9AFGDS@mta7.pltn13.pbi.net> for isis-wg@spider.juniper.net; Wed, 17 Apr 2002 13:04:28 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt - additions and c orrections To: "Martin, Christian" Cc: "'Tony Przygienda'" , "'isis-wg@external.juniper.net'" , "'stefano previdi'" , Tony Li , Hannes Gredler , naiming@redback.com, bneal@broadwing.com Reply-to: prz@redback.com Message-id: <3CBDB5EA.643A7A78@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <94B9091E1149D411A45C00508BACEB35015F2DB5@entmail.gnilink.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 10:50:34 -0700 Content-Transfer-Encoding: 7BIT "Martin, Christian" wrote: > Ok, I see the issue. How about this: > > 6. Ordering of Tags > > The semantics of the tag order are implementation-dependent. That > is, there is no implied meaning to the ordering of the tags that > indicates a certain operation or set of operations need be performed, > based on the order of the tags. Each tag SHOULD be treated as an > autonomous identifier that MAY be used in policy to perform a policy > action. Whether or not tag A preceeds or succeeds tag B SHOULD not > change the meaning of the tag set. However, an implementation MAY > wish to preserve tag ordering such that an ordered set of tags has > meaning to the local policy. > ok, vague enough to not specify much but make people to understand there are possible issue when they play with stuff. I hope more people get vocal here if they need that stuff thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 17 19:26:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10807 for ; Wed, 17 Apr 2002 19:26:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HNBGt72223; Wed, 17 Apr 2002 16:11:16 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3HMvYt72132 for ; Wed, 17 Apr 2002 15:57:34 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 13:24:12 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DB6@entmail.gnilink.com> From: "Martin, Christian" To: "Martin, Christian" , "'Tony Przygienda'" Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt - a dditions and c orrections MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Apr 2002 13:24:11 -0400 > >Agreed. The tag changes can only occur at area boundaries >where TLV 135 is copied into the new area's LSP. As well as TLV 235... Chris _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 05:27:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29805 for ; Thu, 18 Apr 2002 05:27:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3I9B1t75002; Thu, 18 Apr 2002 02:11:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3I9Alt74990 for ; Thu, 18 Apr 2002 02:10:47 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp40.cisco.com [10.50.0.39]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA27892; Thu, 18 Apr 2002 10:23:27 +0100 (BST) Message-Id: <4.3.2.7.2.20020418100312.026e3b38@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Matthew Noble" From: mike shand Cc: "'Isis-Wg (E-mail)" In-Reply-To: <000001c1e549$1049f460$8fdb14ac@ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Re: receipt of CSNP's during restart Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 10:20:33 +0100 At 14:16 16/04/2002 +0100, Matthew Noble wrote: >Mike > >An interesting point that I think you may need to highlight in the draft. > >Say that the restarting node is of type 1/2 and that there are multiple >nodes on a given LAN, and that these other nodes on the LAN are of mixed >type (levels 1, 2 and 1/2). In this case the restarter will in fact receive >2 sets of complete CSNP's over that (LAN) circuit and the T1 timer for that >circuit should not be cancelled until both sets are received (as well as at >least one ACK being received). Yes that is the way it is supposed to work. You are right, this could do with clarifying in the text. >However this does lead to the issue of what to do in this circuitstance when >the restarter is type 1/2 but the other nodes on the LAN are only either >level 1 _or_ level 2. May be in that case, although the node is type 1/2, >the circuit should be congfigured as either type 1 or type 2 as appropriate. >In that case the restart knows only to wait for that single CSNP. Well, you can certainly tell by looking at the circuit type field of the IIHs you receive whether there is a router out there for level1 and one for level 2. If there is, you should wait hopefully for the appropriate CSNP. If you don't see one, then maybe you could give up rather more quickly. I must confess I hadn't thought of trying to optimize that though. Mike >Any comments? > >Thanks >Matt _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 15:39:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20556 for ; Thu, 18 Apr 2002 15:39:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IJM1t77860; Thu, 18 Apr 2002 12:22:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IJLct77848 for ; Thu, 18 Apr 2002 12:21:38 -0700 (PDT) (envelope-from rsrivats@cisco.com) Received: from router.cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3IJYKOR014379; Thu, 18 Apr 2002 12:34:20 -0700 (PDT) From: Radhika Srivatsa To: mike shand cc: Matthew Noble , "'Isis-Wg (E-mail)" Subject: Re: [Isis-wg] Re: receipt of CSNP's during restart In-Reply-To: <4.3.2.7.2.20020418100312.026e3b38@jaws.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 15:34:20 -0400 (EDT) In continuation of this, what about the cancellation of T2 ? Suppose we have only 2 routers and both of these have only L2 adjacencies between them (each router is in a different area altho' the interface is configured for both L1L2) , then the T2 timer for L1 will never get cancelled as a part of LSPDB synchronization (since there wont be any CSNP received over the L1 area) and will eventually get cancelled only when the IETF-restart completes. Is that acceptable ? Or, we could see if a particular area has any adjacencies within itself and if there are no adjacencies in that area, then we can cancel T2 for that area. Thoughts ? thanks -radhika On Thu, 18 Apr 2002, mike shand wrote: > At 14:16 16/04/2002 +0100, Matthew Noble wrote: > >Mike > > > >An interesting point that I think you may need to highlight in the draft. > > > >Say that the restarting node is of type 1/2 and that there are multiple > >nodes on a given LAN, and that these other nodes on the LAN are of mixed > >type (levels 1, 2 and 1/2). In this case the restarter will in fact receive > >2 sets of complete CSNP's over that (LAN) circuit and the T1 timer for that > >circuit should not be cancelled until both sets are received (as well as at > >least one ACK being received). > > Yes that is the way it is supposed to work. You are right, this could do > with clarifying in the text. > > > >However this does lead to the issue of what to do in this circuitstance when > >the restarter is type 1/2 but the other nodes on the LAN are only either > >level 1 _or_ level 2. May be in that case, although the node is type 1/2, > >the circuit should be congfigured as either type 1 or type 2 as appropriate. > >In that case the restart knows only to wait for that single CSNP. > > Well, you can certainly tell by looking at the circuit type field of the > IIHs you receive whether there is a router out there for level1 and one for > level 2. If there is, you should wait hopefully for the appropriate CSNP. > If you don't see one, then maybe you could give up rather more quickly. I > must confess I hadn't thought of trying to optimize that though. > > Mike > > > >Any comments? > > > >Thanks > >Matt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 16:49:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22492 for ; Thu, 18 Apr 2002 16:49:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IKXht78222; Thu, 18 Apr 2002 13:33:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IKSbt78193 for ; Thu, 18 Apr 2002 13:28:37 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3IKfj48029434; Thu, 18 Apr 2002 16:41:45 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABG01201; Thu, 18 Apr 2002 16:41:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20020418162330.01e4f008@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: Jeff Learman Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27088371==_.ALT" Subject: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 16:41:04 -0400 --=====================_27088371==_.ALT Content-Type: text/plain; charset="us-ascii" (Changing the group to isis-wg.) At 04:03 PM 4/18/2002, Ravindra Sunkad wrote: >Sections 4.2 and 4.3 of http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt do discuss IP forwarding over unnumbered LAN interfaces. Then again this applies only to LANs that are simulating PT-PT operation. Thanks, Ravi, I missed that one somehow. It's probably in my "stuff I gotta read" folder ;-) Concerning the draft: (4.1 paragraph 2) What's an "unnumbered IP address"? Does this paragraph mean that an address must be advertised in IIH PDUs, but the same address may be used on other point-to-point circuits on the same router? Why wasn't a standard multicast address chosen to avoid the need for ARP? ARP shouldn't be required when using ISIS anyway, since IIHs are sufficient for MAC address resolution. And if ARP isn't required, then the interface IP address wouldn't be required either, I believe. But if a standard multicast address is used, the issue becomes moot. (Sorry for the johnny-come-lately questions.) Thanks, Jeff --=====================_27088371==_.ALT Content-Type: text/html; charset="us-ascii"
(Changing the group to isis-wg.)

At 04:03 PM 4/18/2002, Ravindra Sunkad wrote:
Sections 4.2 and 4.3 of http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt do discuss IP forwarding over unnumbered LAN interfaces. Then again this applies only to LANs that are simulating PT-PT operation.

Thanks, Ravi, I missed that one somehow.  It's probably in my
"stuff I gotta read" folder ;-)

Concerning the draft:

(4.1 paragraph 2)  What's an "unnumbered IP address"?   Does this
paragraph mean that an address must be advertised in IIH PDUs, but the
same address may be used on other point-to-point circuits on the same
router?

Why wasn't a standard multicast address chosen to avoid the need for ARP?

ARP shouldn't be required when using ISIS anyway, since IIHs are sufficient
for MAC address resolution.  And if ARP isn't required, then the interface
IP address wouldn't be required either, I believe.  But if a standard
multicast address is used, the issue becomes moot.

(Sorry for the johnny-come-lately questions.)

Thanks,
Jeff
--=====================_27088371==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 18:08:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24290 for ; Thu, 18 Apr 2002 18:08:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ILpQt78613; Thu, 18 Apr 2002 14:51:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ILeFt78559 for ; Thu, 18 Apr 2002 14:40:15 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 8FE7D4BA215; Thu, 18 Apr 2002 14:53:01 -0700 (PDT) To: Jeff Learman Cc: "Ravindra Sunkad" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt In-reply-to: Mail from Jeff Learman dated Thu, 18 Apr 2002 16:41:04 EDT <4.3.2.7.2.20020418162330.01e4f008@dingdong.cisco.com> From: Naiming Shen Message-Id: <20020418215301.8FE7D4BA215@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 14:53:01 -0700 ] ] Concerning the draft: ] ] (4.1 paragraph 2) What's an "unnumbered IP address"? Does this ] paragraph mean that an address must be advertised in IIH PDUs, but the ] same address may be used on other point-to-point circuits on the same ] router? i think the "unnumbered" means to borrow some address from one of the internal/connected addresses. yes, it should be advertised in the IIH. yes, it maybe used for multiple p2p isis ckts on the same router. Most implementations do this on normal p2p ckt today. ] ] Why wasn't a standard multicast address chosen to avoid the need for ARP? ] ] ARP shouldn't be required when using ISIS anyway, since IIHs are sufficient ] for MAC address resolution. And if ARP isn't required, then the interface ] IP address wouldn't be required either, I believe. But if a standard ] multicast address is used, the issue becomes moot. ARP maybe used because we want to forward IP traffic, not because we need to exchange ISIS routing packets. To forward traffic on a multi access interface, you need to have a MAC. Or did I miss your question? ] ] (Sorry for the johnny-come-lately questions.) - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 18:47:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24879 for ; Thu, 18 Apr 2002 18:47:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IMX8t78837; Thu, 18 Apr 2002 15:33:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3IMP0t78789 for ; Thu, 18 Apr 2002 15:25:00 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3IMc7hf007822; Thu, 18 Apr 2002 18:38:08 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABG05098; Thu, 18 Apr 2002 18:37:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20020418182503.01e5aa30@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Naiming Shen From: Jeff Learman Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt Cc: "Ravindra Sunkad" , isis-wg@spider.juniper.net In-Reply-To: <20020418215301.8FE7D4BA215@prattle.redback.com> References: <4.3.2.7.2.20020418162330.01e4f008@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 18:37:41 -0400 At 05:53 PM 4/18/2002, Naiming Shen wrote: > ] > ] Why wasn't a standard multicast address chosen to avoid the need for ARP? > ] > ] ARP shouldn't be required when using ISIS anyway, since IIHs are sufficient > ] for MAC address resolution. And if ARP isn't required, then the interface > ] IP address wouldn't be required either, I believe. But if a standard > ] multicast address is used, the issue becomes moot. > >ARP maybe used because we want to forward IP traffic, not because we >need to exchange ISIS routing packets. To forward traffic on a multi >access interface, you need to have a MAC. Or did I miss your question? I think you missed what I'm saying. First, (ignoring the PTP issue) when using ISIS you don't need ARP to resolve the MAC address of a neighbor router, because you received an IIH from it and can get the MAC address from that. ARP need not be the only entity allowed to create an address binding. This is an implementation issue, not a protocol issue. But if we assign a standard multicast MAC address on PTP Ethernet, then neither ARP nor the IIH MAC address is required. It acts just like any other PTP link, whatever you send gets to the other end. This also simplifies interoperability. If there is an implementation that croaks upon receiving a PTP IIH on a broadcast LAN, nobody would know because it never happened before. If we use a (new) multicast address for ALL packets on the link (not just IP packets, but also ISIS packets), then there would be no worry about a naive implementation receiving these packets when they're inadvertently unleashed on a broadcast LAN. They would be ignored because no systems would be listening to that multicast address on the LAN. Regards, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 21:38:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28021 for ; Thu, 18 Apr 2002 21:38:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J1Mct79680; Thu, 18 Apr 2002 18:22:38 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J12Nt79584 for ; Thu, 18 Apr 2002 18:02:23 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 419721B8EF0; Thu, 18 Apr 2002 18:15:10 -0700 (PDT) To: Jeff Learman Cc: "Ravindra Sunkad" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt In-reply-to: Mail from Jeff Learman dated Thu, 18 Apr 2002 18:37:41 EDT <4.3.2.7.2.20020418182503.01e5aa30@dingdong.cisco.com> From: Naiming Shen Message-Id: <20020419011510.419721B8EF0@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 18:15:10 -0700 Jeff, ] First, (ignoring the PTP issue) when using ISIS you don't need ARP to ] resolve the MAC address of a neighbor router, because you received an ] IIH from it and can get the MAC address from that. ARP need ] not be the only entity allowed to create an address binding. This is ] an implementation issue, not a protocol issue. True. This draft is trying to do things using the most natual way we know of, such as using ARP on a LAN:-) Sure, an implementation can be done that as soon as IS-IS is configured, ARP is automatically disabled, and IS-IS is used directly programming the linecards, etc. Some people would think it's a layer violation. This draft lists this mechanism as "2. MAC address gleaning" and its up to the implementations. ] ] But if we assign a standard multicast MAC address on PTP Ethernet, ] then neither ARP nor the IIH MAC address is required. It acts just ] like any other PTP link, whatever you send gets to the other end. This is also listed as "4. Broadcast/multicast/proprietary". But notice that, we are not only talking about two devices on a LAN, we are also dealing with vLANs. If we use multicast mac address for sending traffic, first of all, all the linecards need some change to recognize this new mac; and all the vLAN routers on this physical LAN have to read the packet and drop on wrong vLAN id; And in the case of a LAN, even though there is only two ISIS routers, but there can be other IP devices/routers, if they happen to ok this mac, then they will take in all the traffic not meant for them. ] ] This also simplifies interoperability. If there is an implementation ] that croaks upon receiving a PTP IIH on a broadcast LAN, nobody would ] know because it never happened before. If we use a (new) multicast ] address for ALL packets on the link (not just IP packets, but also ] ISIS packets), then there would be no worry about a naive implementation ] receiving these packets when they're inadvertently unleashed on a ] broadcast LAN. They would be ignored because no systems would be ] listening to that multicast address on the LAN. ] I hope people do some basic testing before they suddenly enable this on their backbone. Any reasonable implementation should just ignore that "wrong" pkt, if not, then we all have one less competitors;-) thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 18 22:43:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00199 for ; Thu, 18 Apr 2002 22:43:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J2S1t79980; Thu, 18 Apr 2002 19:28:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J2RJt79968 for ; Thu, 18 Apr 2002 19:27:19 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA00546; Thu, 18 Apr 2002 19:39:57 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G8M7SA>; Thu, 18 Apr 2002 19:39:57 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F96C@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Learman'" , Naiming Shen Cc: Ravindra Sunkad , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Apr 2002 19:39:56 -0700 There are a number of ways to resolve this issue - each of which probably presents different degrees of difficulty for forwarding plane implementations. 1)All packets could be sent with the broadcast address. This is functionally equivalent to what the implied destination address is on PtPt links - and seems as functional as a new multicast address with the advantage that we don't have to carve out a new multicast address and potentially stress the limits of multicast address registration in the hardware. 2)An implementation could assign static ARP entries 3)Routing protocol could provide ARP entries based on info from the hello messages. Note that this works well for IS-IS but doesn't help OSPF. 4)If the address of a loopback interface is always advertised in the case of an unnumbered P2P/LAN and the local ARP implementation always replied to ARP queries for the IP address of ANY local interface (not just the interface associated with the port on which the ARP request is received) then the destination MAC address could be discovered. I suspect "your mileage may differ" is the applicable phrase in that what may be easy for one router to implement may be awkward for another. This seems the sort of thing which should be tried first on a number of platforms before deciding which strategy/strategies to endorse. Perhaps those who have already done this might share what solution(s) they used. Les > > At 05:53 PM 4/18/2002, Naiming Shen wrote: > > ] > > ] Why wasn't a standard multicast address chosen to avoid > the need for ARP? > > ] > > ] ARP shouldn't be required when using ISIS anyway, since > IIHs are sufficient > > ] for MAC address resolution. And if ARP isn't required, > then the interface > > ] IP address wouldn't be required either, I believe. But > if a standard > > ] multicast address is used, the issue becomes moot. > > > >ARP maybe used because we want to forward IP traffic, not because we > >need to exchange ISIS routing packets. To forward traffic on a multi > >access interface, you need to have a MAC. Or did I miss your > question? > > I think you missed what I'm saying. > > First, (ignoring the PTP issue) when using ISIS you don't need ARP to > resolve the MAC address of a neighbor router, because you received an > IIH from it and can get the MAC address from that. ARP need > not be the only entity allowed to create an address binding. This is > an implementation issue, not a protocol issue. > > But if we assign a standard multicast MAC address on PTP Ethernet, > then neither ARP nor the IIH MAC address is required. It acts just > like any other PTP link, whatever you send gets to the other end. > > This also simplifies interoperability. If there is an implementation > that croaks upon receiving a PTP IIH on a broadcast LAN, nobody would > know because it never happened before. If we use a (new) multicast > address for ALL packets on the link (not just IP packets, but also > ISIS packets), then there would be no worry about a naive > implementation > receiving these packets when they're inadvertently unleashed on a > broadcast LAN. They would be ignored because no systems would be > listening to that multicast address on the LAN. > > Regards, > Jeff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 03:08:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12226 for ; Fri, 19 Apr 2002 03:08:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J6r1t81127; Thu, 18 Apr 2002 23:53:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3J6qbt81115 for ; Thu, 18 Apr 2002 23:52:38 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp56.cisco.com [10.50.0.55]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA05850; Fri, 19 Apr 2002 08:05:21 +0100 (BST) Message-Id: <4.3.2.7.2.20020419080419.00b7b850@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Radhika Srivatsa From: mike shand Subject: Re: [Isis-wg] Re: receipt of CSNP's during restart Cc: Matthew Noble , "'Isis-Wg (E-mail)" In-Reply-To: References: <4.3.2.7.2.20020418100312.026e3b38@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 08:05:12 +0100 At 15:34 18/04/2002 -0400, Radhika Srivatsa wrote: >In continuation of this, what about the cancellation of T2 ? >Suppose we have only 2 routers and both of these have only L2 adjacencies >between them (each router is in a different area altho' the interface is >configured for both L1L2) , then the T2 timer for L1 will never get >cancelled as a part of LSPDB synchronization (since there wont be any CSNP >received over the L1 area) and will eventually get cancelled only when the >IETF-restart completes. Is that acceptable ? > >Or, we could see if a particular area has any adjacencies within itself >and if there are no adjacencies in that area, then we can cancel T2 for that >area. If an L1/L2 has no L1 adjacencies, then we can assume that L1 is already "synchronized". Mike >Thoughts ? > >thanks > >-radhika > >On Thu, 18 Apr 2002, mike shand wrote: > > > At 14:16 16/04/2002 +0100, Matthew Noble wrote: > > >Mike > > > > > >An interesting point that I think you may need to highlight in the draft. > > > > > >Say that the restarting node is of type 1/2 and that there are multiple > > >nodes on a given LAN, and that these other nodes on the LAN are of mixed > > >type (levels 1, 2 and 1/2). In this case the restarter will in fact > receive > > >2 sets of complete CSNP's over that (LAN) circuit and the T1 timer for > that > > >circuit should not be cancelled until both sets are received (as well > as at > > >least one ACK being received). > > > > Yes that is the way it is supposed to work. You are right, this could do > > with clarifying in the text. > > > > > > >However this does lead to the issue of what to do in this > circuitstance when > > >the restarter is type 1/2 but the other nodes on the LAN are only either > > >level 1 _or_ level 2. May be in that case, although the node is type 1/2, > > >the circuit should be congfigured as either type 1 or type 2 as > appropriate. > > >In that case the restart knows only to wait for that single CSNP. > > > > Well, you can certainly tell by looking at the circuit type field of the > > IIHs you receive whether there is a router out there for level1 and one for > > level 2. If there is, you should wait hopefully for the appropriate CSNP. > > If you don't see one, then maybe you could give up rather more quickly. I > > must confess I hadn't thought of trying to optimize that though. > > > > Mike > > > > > > >Any comments? > > > > > >Thanks > > >Matt > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 10:16:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20889 for ; Fri, 19 Apr 2002 10:16:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JE01t83439; Fri, 19 Apr 2002 07:00:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JDxSt83421 for ; Fri, 19 Apr 2002 06:59:28 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JECX0i015186; Fri, 19 Apr 2002 10:12:33 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABG16723; Fri, 19 Apr 2002 10:12:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20020419093101.035eb2a8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: Jeff Learman Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt Cc: Naiming Shen , Ravindra Sunkad , isis-wg@spider.juniper.net In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F96C@avalon.pluris.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 10:11:02 -0400 At 10:39 PM 4/18/2002, Les Ginsberg wrote: >There are a number of ways to resolve this issue - each of which probably >presents different degrees of difficulty for forwarding plane >implementations. > >1)All packets could be sent with the broadcast address. This is functionally >equivalent to what the implied destination address is on PtPt links - and >seems as functional as a new multicast address with the advantage that we >don't have to carve out a new multicast address and potentially stress the >limits of multicast address registration in the hardware. I think that a new multicast address would be far better than a broadcast address because it would cause fewer problems when (not IF, but WHEN) an interface configured for PTP is attached to a broadcast LAN. It should not be difficult to assign a multicast address. Regards, Jeff >2)An implementation could assign static ARP entries > >3)Routing protocol could provide ARP entries based on info from the hello >messages. Note that this works well for IS-IS but doesn't help OSPF. > >4)If the address of a loopback interface is always advertised in the case of >an unnumbered P2P/LAN and the local ARP implementation always replied to ARP >queries for the IP address of ANY local interface (not just the interface >associated with the port on which the ARP request is received) then the >destination MAC address could be discovered. > >I suspect "your mileage may differ" is the applicable phrase in that what >may be easy for one router to implement may be awkward for another. This >seems the sort of thing which should be tried first on a number of platforms >before deciding which strategy/strategies to endorse. Perhaps those who have >already done this might share what solution(s) they used. > > Les > > > >> >> At 05:53 PM 4/18/2002, Naiming Shen wrote: >> > ] >> > ] Why wasn't a standard multicast address chosen to avoid >> the need for ARP? >> > ] >> > ] ARP shouldn't be required when using ISIS anyway, since >> IIHs are sufficient >> > ] for MAC address resolution. And if ARP isn't required, >> then the interface >> > ] IP address wouldn't be required either, I believe. But >> if a standard >> > ] multicast address is used, the issue becomes moot. >> > >> >ARP maybe used because we want to forward IP traffic, not because we >> >need to exchange ISIS routing packets. To forward traffic on a multi >> >access interface, you need to have a MAC. Or did I miss your >> question? >> >> I think you missed what I'm saying. >> >> First, (ignoring the PTP issue) when using ISIS you don't need ARP to >> resolve the MAC address of a neighbor router, because you received an >> IIH from it and can get the MAC address from that. ARP need >> not be the only entity allowed to create an address binding. This is >> an implementation issue, not a protocol issue. >> >> But if we assign a standard multicast MAC address on PTP Ethernet, >> then neither ARP nor the IIH MAC address is required. It acts just >> like any other PTP link, whatever you send gets to the other end. >> >> This also simplifies interoperability. If there is an implementation >> that croaks upon receiving a PTP IIH on a broadcast LAN, nobody would >> know because it never happened before. If we use a (new) multicast >> address for ALL packets on the link (not just IP packets, but also >> ISIS packets), then there would be no worry about a naive >> implementation >> receiving these packets when they're inadvertently unleashed on a >> broadcast LAN. They would be ignored because no systems would be >> listening to that multicast address on the LAN. >> >> Regards, >> Jeff >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@spider.juniper.net >> http://spider.juniper.net/mailman/listinfo/isis-wg >> _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 10:35:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21730 for ; Fri, 19 Apr 2002 10:35:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JEKht83607; Fri, 19 Apr 2002 07:20:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JEH4t83567 for ; Fri, 19 Apr 2002 07:17:05 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Jeff Learman'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 10:29:41 -0400 > I think that a new multicast address would be far better than > a broadcast address because it would cause fewer problems > when (not IF, but WHEN) an interface configured for PTP > is attached to a broadcast LAN. It should > not be difficult to assign a multicast address. > > Regards, > Jeff L. I think this is out of scope for this document. We need to document what works today, what assumptions are made, and what you need to do in order to interoperate with existing practice. One conclusion may be that certain configurations should not be expected to work with all implementations. This isn't normative: this is reality. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 10:56:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22432 for ; Fri, 19 Apr 2002 10:56:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JEfht83750; Fri, 19 Apr 2002 07:41:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JEc3t83727 for ; Fri, 19 Apr 2002 07:38:03 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JEojUe018822; Fri, 19 Apr 2002 10:50:45 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABG17897; Fri, 19 Apr 2002 10:50:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20020419104903.03624ef8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 10:50:03 -0400 Jeff, this is isis-wg, not isis-update. Definitely out-of-scope for isis-update. At 10:29 AM 4/19/2002, Jeff Parker wrote: > >> I think that a new multicast address would be far better than >> a broadcast address because it would cause fewer problems >> when (not IF, but WHEN) an interface configured for PTP >> is attached to a broadcast LAN. It should >> not be difficult to assign a multicast address. >> >> Regards, >> Jeff L. > >I think this is out of scope for this document. >We need to document what works today, what assumptions >are made, and what you need to do in order to >interoperate with existing practice. > >One conclusion may be that certain configurations >should not be expected to work with all implementations. >This isn't normative: this is reality. > >- jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 15:42:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24397 for ; Fri, 19 Apr 2002 15:42:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JJR1t84945; Fri, 19 Apr 2002 12:27:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JJQEt84933 for ; Fri, 19 Apr 2002 12:26:14 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 4CDE1F2C59; Fri, 19 Apr 2002 12:39:05 -0700 (PDT) Message-ID: <3CC060FE.8E700CC2@redback.com> From: Tony Przygienda Reply-To: prz@redback.com X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker Cc: "'Jeff Learman'" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 11:25:02 -0700 Content-Transfer-Encoding: 7bit Jeff Parker wrote: > > > I think that a new multicast address would be far better than > > a broadcast address because it would cause fewer problems > > when (not IF, but WHEN) an interface configured for PTP > > is attached to a broadcast LAN. It should > > not be difficult to assign a multicast address. > > > > Regards, > > Jeff L. > > I think this is out of scope for this document. > We need to document what works today, what assumptions > are made, and what you need to do in order to > interoperate with existing practice. > > One conclusion may be that certain configurations > should not be expected to work with all implementations. > This isn't normative: this is reality. ptp over lan draft can still be influenced in my opinion sicne we don't have large deployment on stake based on my understanding. Then again, Jeff probably misunderstood which list this is being sent to ;) -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 16:01:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26623 for ; Fri, 19 Apr 2002 16:01:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JJkPt85066; Fri, 19 Apr 2002 12:46:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JJZdt84995 for ; Fri, 19 Apr 2002 12:35:39 -0700 (PDT) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3JJmV667897 for ; Fri, 19 Apr 2002 12:48:31 -0700 (PDT) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Fri, 19 Apr 2002 12:39:49 -0700 Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id AF39318D3E3 for ; Fri, 19 Apr 2002 12:41:43 -0700 (PDT) Message-ID: <3CC0619C.5BE59482@redback.com> From: Tony Przygienda Reply-To: prz@redback.com X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2002 19:39:50.0077 (UTC) FILETIME=[F82E06D0:01C1E7D9] Subject: [Isis-wg] (yet another) last call for draft-ietf-isis-3way-06 ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 11:27:41 -0700 Content-Transfer-Encoding: 7bit draft-ietf-isis-3way-06 underwent in some folks' minds a change significant enough to justify another 2 weeks period till 5/3/02 for a last call. -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 17:45:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07489 for ; Fri, 19 Apr 2002 17:45:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JLU1t85579; Fri, 19 Apr 2002 14:30:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JLO4t85533 for ; Fri, 19 Apr 2002 14:24:04 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 08008262811; Fri, 19 Apr 2002 14:36:56 -0700 (PDT) To: Jeff Learman Cc: Les Ginsberg , Ravindra Sunkad , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt In-reply-to: Mail from Jeff Learman dated Fri, 19 Apr 2002 10:11:02 EDT <4.3.2.7.2.20020419093101.035eb2a8@dingdong.cisco.com> From: Naiming Shen Message-Id: <20020419213656.08008262811@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 14:36:55 -0700 ] > ] >1)All packets could be sent with the broadcast address. This is functionally ] >equivalent to what the implied destination address is on PtPt links - and ] >seems as functional as a new multicast address with the advantage that we ] >don't have to carve out a new multicast address and potentially stress the ] >limits of multicast address registration in the hardware. ] ] I think that a new multicast address would be far better than a broadcast ] address because it would cause fewer problems when (not IF, but WHEN) an ] interface configured for PTP is attached to a broadcast LAN. It should ] not be difficult to assign a multicast address. It may not be much better. I have seen people run IGP over the LAN on some of the NAPs between their own peering routers. Assume multicast mac is used, and they run p2p-over-lan for the IGP adjacency. The data packets can be picked up by multiple routers on the LAN other than your neighbor and this will cause serious problems. I agree with Les that, an implementation can offer a configuration knob to allow broadcast MAC address being used if the user is sure about there is only two devices on the physical LAN. Its up to the implementation and the user. Yes, a multicast MAC will also work in this case, but why bother? why should every piece of hardware be touched to recognize this new MAC just for this p2p-over-lan? Its not like the existing mechanisms all fail. thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 18:04:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09711 for ; Fri, 19 Apr 2002 18:04:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JLo1t85713; Fri, 19 Apr 2002 14:50:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JLnlt85698 for ; Fri, 19 Apr 2002 14:49:47 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from there (dhcp-128-107-212-91.cisco.com [128.107.212.91]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id AAA23375; Sat, 20 Apr 2002 00:02:25 +0200 (MET DST) Message-Id: <200204192202.AAA23375@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Naiming Shen , Jeff Learman Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt X-Mailer: KMail [version 1.3.1] Cc: Les Ginsberg , Ravindra Sunkad , isis-wg@spider.juniper.net References: <20020419213656.08008262811@prattle.redback.com> In-Reply-To: <20020419213656.08008262811@prattle.redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3JLnlt85699 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 20 Apr 2002 00:02:21 +0200 Content-Transfer-Encoding: 8bit On Friday 19 April 2002 23:36, Naiming Shen wrote: > ] > > ] >1)All packets could be sent with the broadcast address. This is functionally > ] >equivalent to what the implied destination address is on PtPt links - and > ] >seems as functional as a new multicast address with the advantage that we > ] >don't have to carve out a new multicast address and potentially stress the > ] >limits of multicast address registration in the hardware. > ] > ] I think that a new multicast address would be far better than a broadcast > ] address because it would cause fewer problems when (not IF, but WHEN) an > ] interface configured for PTP is attached to a broadcast LAN. It should > ] not be difficult to assign a multicast address. > > It may not be much better. I have seen people run IGP over the LAN on > some of the NAPs between their own peering routers. Assume multicast > mac is used, and they run p2p-over-lan for the IGP adjacency. The data > packets can be picked up by multiple routers on the LAN other than your > neighbor and this will cause serious problems. > > I agree with Les that, an implementation can offer a configuration > knob to allow broadcast MAC address being used if the user is sure about > there is only two devices on the physical LAN. Its up to the implementation > and the user. absolutely. I woudn't force the use of any specifc address. I believe the scope of the draft is to give flexibility on the way the igp sees the link, but not on the way forwarding is done on the wire. So, give generic recommendations but not at the point of which mac address is supposed to be used. s. > Yes, a multicast MAC will also work in this case, but why > bother? why should every piece of hardware be touched to recognize this new > MAC just for this p2p-over-lan? Its not like the existing mechanisms all > fail. > > thanks. > - Naiming > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 19 19:36:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19103 for ; Fri, 19 Apr 2002 19:36:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3JNL1t86128; Fri, 19 Apr 2002 16:21:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g3JNKVt86116 for ; Fri, 19 Apr 2002 16:20:31 -0700 (PDT) (envelope-from lqmao@yahoo.com) Message-ID: <20020419233323.98158.qmail@web11604.mail.yahoo.com> Received: from [63.98.44.82] by web11604.mail.yahoo.com via HTTP; Fri, 19 Apr 2002 16:33:23 PDT From: Lawrence Mao To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] IS-IS on UPSR ring Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 16:33:23 -0700 (PDT) Hi all, If the IS-IS needs to be supported on a SONET UPSR ring, throught its DCC channel (note that the ring is uni-directional), say, if I have 4 nodes on a ring: A --> B --> C --> D - ^ | |-------------------- what kind of modifications need to be made in order to let the protocol work properly (note all interfaces are p2p type)? 2nd question is, if the interface is unnumbered, how is its routing table generated? Use routerID? Thanks, -- Lawrence __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 20 03:00:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28976 for ; Sat, 20 Apr 2002 03:00:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3K6ght88237; Fri, 19 Apr 2002 23:42:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3K6dat88214 for ; Fri, 19 Apr 2002 23:39:36 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id CDC0039B5AF; Fri, 19 Apr 2002 23:52:30 -0700 (PDT) To: mshand@cisco.com Cc: naiming@redback.com, isis-wg@spider.juniper.net From: Naiming Shen Message-Id: <20020420065230.CDC0039B5AF@prattle.redback.com> Subject: [Isis-wg] a few comments on ietf restart isis draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Apr 2002 23:52:30 -0700 Hi Mike, I have a few comments on draft-ietf-isis-restart-00.txt, I apologize for the late discussion. It was in my "stuff I gotta read" folder for too long (something just learned from Jeff) ;-) (1) TLV code [TBD] seems we have a code for this now. (2) page 4, the 2nd paragraph, "a) DO NOT refresh the timer on the adjacency, ..." I have big problem with this. The receiving router has a good adjacency to the neighbor which just restarted, this neighbor asks for help. The restarting neighbor sent out an IIH containing RR bit set, and also has its "holding time" value in this IIH. Why should the receiving router not to refresh the timer using the latest "holding time" value in this re-start IIH? I think in this case, the receiving router is "lucky" enough to get an IIH(with RR bit) from the restarting router before it times this adjacency out, so the receiving router should do everything to help the neighbor to complete the restart process. for example: the receiving router only has 1 second left on this adjacency, and received the RR bit set IIH on this adjacency. This IIH has the "holding time" of 30 seconds. If it wants to help the neighbor to complete a good restart, should the receiving router times out this adjacency in 1 second, or should the receiving router holds on this adjacency for another 30 seconds? I would definitely go for the later. The only "harm" I can see if updating the timer is that, if the restart router after sending out the re-start IIHs, then crashed again and never come back. If this happens, then the convergence is a little slow, but this may not affect the forwarding and its a very rare case. Yes, the vendors should make the restart come back way before the neighbors holding time expires, but it may not always be so easy; Yes, the normal holding time can be configured long enough so it always handles whatever time restart takes, but that seems going the opposite direction from IGP milli-second convergence. I would change "DO NOT" into "MUST" here. 3) page 4, paragraph 3 and 4 Probably need to say something explicitly about the ordering of those packets. If we have IIH(with RA bit), CSNPs and LSPs to be sent to help the neighbor restart, we need to make sure the IIH goes out first. Otherwise the CSNPs or LSPs can be dropped by the re-starting neighbor since it does not have an adjacency yet. "without waiting for any currently running timer interval to expire" may refer to the same idea, but it should be spelled out. 4) page 4, paragraph 5 "i.e. if there was no adjacency" Should add "or the adjacency is not in the "UP" state". 5) page 4, last two paragraphs "contains an empty ..." and "option with state "Down" and with empty .." Probably those two sentences should be removed. Because on page 4 the first paragraph says: "irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Adjacency State" option"... Which means, as long as the RR bit is set in this re-start tlv, we don't care about the ISN tlv is empty or NOT empty and we don't care about what state this IIH has. Which is good. I'm not just nit-picking on language here, basically this RR bit is a mechanism for IS-IS to re-acquire LSPs from neighbors. It can be used for some other applications other than graceful restart. In those cases, we don't want to send out empty ISN TLVs or in a "Down" state. Also we don't want the neighbors to ignore my "holding time" either;-) (see the comment #2). 6) levels of IIH with RR bit set The draft probably should say clearly about the levels: on the LAN, if both levels are active on the interface, it should send out two IIHs with the RR bit set, one for each level. The receiving router may respond with two IIHs with RA bit, one for each level where the adjacencies are in UP state. a) b) and c) on page 4 is for each level. on p2p intf, only send one IIH, but the receiving router still needs to check for both levels base on the adjacency usage to send out csnps and lsps. 7) page 3, last paragraph This comment is closely related to comment #2. Assume we DO(opposite from the current draft) update the adjacency timer by the receiving router, then this "Remaining Time" field is no use here. This value set by the Receiving router would be the same as the "holding time" value in the IIH the re-start router just sent out. Thus this re-start TLV can use just one octet in length. The T3 is the minimum value of all the IS-IS intf holding times. And it can be figured out immediately without waiting for neighbors to tell us. It is based on local configure settings. I think about this way: it's reasonable to expect all the interfaces go through the similar amount of time to finish this re-start job. But if we ask the neighbors NOT updating the timers on the adjacencies, it will be very random. Some adjacencies will be timed out in 1 second, some will be in 20 seconds, etc. It's much better to ask them to time out me in, say 20 seconds, across the board. "Since I'm back, give me another chance, and I know my restart process takes xx seconds". Implementations can even offer a config knob to send a different(base on the local configuration size, network topology size and database size, also the vendor implementation, those are all closely related to the re-start time) holding time in this re-start IIH. T3 is the minimum of this "Remaining Time" right now. So if T3 times out, all the normal IIHs are starting to go out on all the interfaces, this means, if one adjacency has low timeout from our neighbors, all our adjacencies may be affected during the restart since they sees the incomplete ISN TLVs in normal IIHs. 8) page 4, paragraph 4 "excluding the transmitting router" An optimization would be, "excluding the transmitting router and only include the routers on the LAN who had re-start TLV in their IIHs". There maybe someone on the LAN running old code, that router just happen to have the highest priority but it can not help the restart neighbor with CSNP and LSPs. So some router with new code should step in now since the information is available. 9) page 5, first paragraph "On expiry of the timer T1, it is restarted and the IIH is re-transmitted as above." I take it that, this is to avoid the first IIH packet got lost, so let's retry. and have a maximum number of retry mentioned in page 6. I think we should not even retry. This graceful restart is not meant to be bullet proof. If the IIHs happen to get lost, we just have a bad day. This is also the same problem if you have multiple neighbors on the same LAN. Your IIH can be lost to one of the neighbors, but as soon as you receive from other neighbors and complete the CSNPs, the T1 will be cancelled. But you have no way to know, that one neighbor didn't receive your re-start IIH, and it will reset the adjacency. The current scheme does not cover that case, and I think its not worth to have retries in general. Thus actually we don't even need the T1. 10) page 8, the 5th paragraph "are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized" I would be very careful setting OL bit here. T3 times out just means we are sending out normal IIHs, that should not affect anything even we have not acquired all the LSPs from neighbors or we haven't finished our SPF. The goal of this graceful restart is to do non-stop forwarding, if we send out our LSPs with OL on, it's not non-stop forwarding any more. Yes our SPF has not finished yet, so what's the hurry? why not let it to finish? Its much better to delay sending out our LSPs(assume topology has not changed during re-start) since routers in the area has our old LSPs containing the same information, than to send out LSPs immaturely with OL bit set. Also in 4.3.1.1, "with the overload bit clear", just a simple comment, some implementation/configurations couple this OL bit with bgp convergence, and usually bgp "converge" takes longer than the IGP lsp synchronization. 11) 3way hello state The draft suggested to send the re-start IIH, with RR bit set, and 3way state in "Down" on the p2p interface. Assume the neighbor sends back the IIH with "UP" state with RA bit set. If we follow the 3way hello draft, we are in "Down", when receives an "Up", the result state is still "Down". And this is not good. We need to setup this adjacency to "Up" state immediately because we need to receive and accept CSNPs and LSPs over this link soon. So the draft needs to suggest the re-starting router either sending out the re-start IIH with "Init" or "Up" state, or specifying not to follow the 3way hello state table in this case and bring the adjacency up immediately. I think the former is better. 12) re-start router lsp acquiring and flooding optimization? If the re-start router has one hundred IS-IS interfaces, at restart, it will receive 100 copies of the databases from all the interfaces assume all the neighbors can help. We also need to flooding all of them to the other 99 interfaces 100 times. If we have a huge database, it can take a while;-) I'm wondering if the re-starting router and all its neighbors can periodically exchange a number of CSNP sets during this synchronization process until the T3 expires on the re-starting router, and until the neighbors sees a "normal" IIH from the re-starting router. This way, the neighbors may not need to send some redundant lsps, and the re-starting router may not need to do unnecessary lsp flooding. thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 20 07:48:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01045 for ; Sat, 20 Apr 2002 07:48:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KBX1t92222; Sat, 20 Apr 2002 04:33:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KBWst92210 for ; Sat, 20 Apr 2002 04:32:54 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3KBje422462; Sat, 20 Apr 2002 13:45:40 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Apr 2002 12:45:44 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB635@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Lawrence Mao'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] IS-IS on UPSR ring MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E860.E5D46B14" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 20 Apr 2002 12:45:43 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E860.E5D46B14 Content-Type: text/plain; charset="iso-8859-1" I cannot answer the question about unidirectional rings. UPSR is a North American thing. My expertise is International market SDH. However I can give you an OPINION on the second question, I would advice anyone building Integrated IS-IS into a SONET/SDH ADM to address the next hop using the System Identifier (NSAP) of the next hop. Because the routing instance on SONET/SDH ADMs is often running on very limited resourses, it can be important to keep the size of routing tables down. One solution that people are looking at is to use a single prefix per ADM, as a circuitless interface, and to run the PPP or LAPD over DCC links unnumbered. There is even some discussion around connecting ADMs together using Ethernet cables, and not assigning any IP address/subnet mask to the LAN ports either. If a link is unnumbered then I suppose that you should put your circuitless interface IP address in as the "Interface IP address" TLV in Hellos. I haven't figured out yet if this will enable ICMP redirects to work on LAN ports. In order to interwork with such a solution, your cannot rely on ARP to find a neighbouring router (you have to use IS-IS to resolve MAC address to NSAP), and you can't refer to the next hop as an IP address (it might not have one). Better to use NSAPs. Note that Integrated IS-IS does allow IP subnetting rules to be broken for connecting routers together, but of course the router needs a correct subnet to be able to ARP for hosts on a LAN port. However if there are no hosts, just two routers then you can't rely on ARP working. You could argue that ARP and correct subnetting isn't needed for connecting two routers together. That said, if you want to guarantee interop with stand alone Integrated IS-IS routers, then you had better support ARPing on LAN interfaces too (if your customer has configured in an IP address / subnet mask). Note that SOME standalone routers will not bring up an adjacency on LAN ports unless they consider their neighbour to be in the same subnet as themselves. That's my opinion. Philip -----Original Message----- From: Lawrence Mao [mailto:lqmao@yahoo.com] Sent: Saturday, April 20, 2002 12:33 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] IS-IS on UPSR ring Hi all, If the IS-IS needs to be supported on a SONET UPSR ring, throught its DCC channel (note that the ring is uni-directional), say, if I have 4 nodes on a ring: A --> B --> C --> D - ^ | |-------------------- what kind of modifications need to be made in order to let the protocol work properly (note all interfaces are p2p type)? 2nd question is, if the interface is unnumbered, how is its routing table generated? Use routerID? Thanks, -- Lawrence __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1E860.E5D46B14 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] IS-IS on UPSR ring

I cannot answer the question about unidirectional = rings. UPSR is a North American thing. My expertise is International = market SDH.

However I can give you an OPINION on the second = question,

I would advice anyone building Integrated IS-IS into = a SONET/SDH ADM to address the next hop using the System Identifier = (NSAP) of the next hop.

Because the routing instance on SONET/SDH ADMs is = often running on very limited resourses, it can be important to keep = the size of routing tables down.

One solution that people are looking at is to use a = single prefix per ADM, as a circuitless interface, and to run the PPP = or LAPD over DCC links unnumbered.  There is even some discussion = around connecting ADMs together using Ethernet cables, and not = assigning any IP address/subnet mask to the LAN ports = either.

If a link is unnumbered then I suppose that you = should put your circuitless interface IP address in as the = "Interface IP address" TLV in Hellos.  I haven't figured = out yet if this will enable ICMP redirects to work on LAN = ports.

In order to interwork with such a solution, your = cannot rely on ARP to find a neighbouring router (you have to use IS-IS = to resolve MAC address to NSAP), and you can't refer to the next hop as = an IP address (it might not have one). Better to use NSAPs.

Note that Integrated IS-IS does allow IP subnetting = rules to be broken for connecting routers together, but of course the = router needs a correct subnet to be able to ARP for hosts on a LAN = port.  However if there are no hosts, just two routers then you = can't rely on ARP working.

You could argue that ARP and correct subnetting isn't = needed for connecting two routers together.

That said, if you want to guarantee interop with = stand alone Integrated IS-IS routers, then you had better support = ARPing on LAN interfaces too (if your customer has configured in an IP = address / subnet mask). Note that SOME standalone routers will not = bring up an adjacency on LAN ports unless they consider their neighbour = to be in the same subnet as themselves.

That's my opinion.

Philip


-----Original Message-----
From: Lawrence Mao [mailto:lqmao@yahoo.com]
Sent: Saturday, April 20, 2002 12:33 AM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] IS-IS on UPSR ring


Hi all,

If the IS-IS needs to be supported on a SONET
UPSR ring, throught its DCC channel (note = that
the ring is uni-directional), say, if I have = 4
nodes on a ring:

    A --> B --> C --> D = -
    = ^            = ;        |
    |--------------------

what kind of modifications need to be made in
order to let the protocol work properly (note
all interfaces are p2p type)?

2nd question is, if the interface is = unnumbered,
how is its routing table generated? Use = routerID?

Thanks,
--
Lawrence

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with = TurboTax
http://taxes.yahoo.com/
_______________________________________________
Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg=

------_=_NextPart_001_01C1E860.E5D46B14-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 20 13:33:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04942 for ; Sat, 20 Apr 2002 13:33:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KHJ1t93683; Sat, 20 Apr 2002 10:19:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KHIPt93671 for ; Sat, 20 Apr 2002 10:18:25 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3KHVGT75393; Sat, 20 Apr 2002 10:31:16 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g3KHVGU03946; Sat, 20 Apr 2002 10:31:16 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200204201731.g3KHVGU03946@cirrus.juniper.net> From: Dave Katz To: naiming@redback.com CC: mshand@cisco.com, naiming@redback.com, isis-wg@spider.juniper.net In-reply-to: <20020420065230.CDC0039B5AF@prattle.redback.com> (message from Naiming Shen on Fri, 19 Apr 2002 23:52:30 -0700) Subject: Re: [Isis-wg] a few comments on ietf restart isis draft References: <20020420065230.CDC0039B5AF@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 20 Apr 2002 10:31:16 -0700 (PDT) (2) page 4, the 2nd paragraph, "a) DO NOT refresh the timer on the adjacency, ..." I have big problem with this. The receiving router has a good adjacency to the neighbor which just restarted, this neighbor asks for help. The restarting neighbor sent out an IIH containing RR bit set, and also has its "holding time" value in this IIH. Why should the receiving router not to refresh the timer using the latest "holding time" value in this re-start IIH? Nischal came up with a variant of this which accomplishes both goals-- accept the hold time from the IIH that causes you to become a restart helper, and then don't refresh after that. This allows scheduled restarts while normally using hold times too short to accomplish the restart. Imagine running with one second hold times--the restarting router could change its announced hold time to 20 seconds in the RR IIH and then restart at its leisure. This still provides bounding for the restart period, just a wee bit longer than it would have been otherwise (at worst the "normal" hold time plus the "restart" hold time.) _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 20 15:26:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06326 for ; Sat, 20 Apr 2002 15:26:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KJC1t94168; Sat, 20 Apr 2002 12:12:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3KJB6t94156 for ; Sat, 20 Apr 2002 12:11:06 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C6FB64F41B9; Sat, 20 Apr 2002 12:24:03 -0700 (PDT) To: Dave Katz Cc: naiming@redback.com, mshand@cisco.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] a few comments on ietf restart isis draft In-reply-to: Mail from Dave Katz dated Sat, 20 Apr 2002 10:31:16 PDT <200204201731.g3KHVGU03946@cirrus.juniper.net> From: Naiming Shen Message-Id: <20020420192403.C6FB64F41B9@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 20 Apr 2002 12:24:03 -0700 ] (2) page 4, the 2nd paragraph, ] ] "a) DO NOT refresh the timer on the adjacency, ..." ] ] I have big problem with this. The receiving router has a good ] adjacency to the neighbor which just restarted, this neighbor ] asks for help. The restarting neighbor sent out an IIH ] containing RR bit set, and also has its "holding time" value ] in this IIH. Why should the receiving router not to refresh the ] timer using the latest "holding time" value in this re-start IIH? ] ] Nischal came up with a variant of this which accomplishes both goals-- ] accept the hold time from the IIH that causes you to become a restart ] helper, and then don't refresh after that. why not refresh after that? I think we should always refresh. Well, it's an implementation issue also, then I don't go into that. there are two cases of restart, scheduled and unscheduled. for scheduled one: since you know you are going down, and you know how long it will take, then send out a "normal"(not with RR bit set) IIH with long-holding-time value, so the neighbor does not even know its a helper, but will hold this adjacnecy for that long. If you set RR bit on this IIH before you going down, I don't think this is good. Since the helper will keep sending LSPs to you which is a waste of resource. At scheduled restart come back, you should send the IIH with RR bit one, this is just part of the the normal re-start. This turns the neighbor into the helper, and it SHOULD refresh the holdtime. for unscheduled scheduled one: its the same as the last paragraph, the IIH turns the neighbor into the helper. So the only difference between those two cases should be the first one will send a normal IIH with large value of holdtime before going down. There is no problem of refreshing it afterwards, since the re-start router is not suppose to send any IIH until the all the adjacencies are well established(T3 expires as in the draft), so it will be good to always refresh the holdtime, no exceptions. thanks. ] ] This allows scheduled restarts while normally using hold times too ] short to accomplish the restart. Imagine running with one second hold ] times--the restarting router could change its announced hold time to ] 20 seconds in the RR IIH and then restart at its leisure. ] ] This still provides bounding for the restart period, just a wee bit longer ] than it would have been otherwise (at worst the "normal" hold time plus ] the "restart" hold time.) - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 10:19:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26555 for ; Mon, 22 Apr 2002 10:19:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ME31t05748; Mon, 22 Apr 2002 07:03:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ME2Tt05736 for ; Mon, 22 Apr 2002 07:02:29 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3MEG0aP013640; Mon, 22 Apr 2002 10:16:00 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-563.cisco.com [10.82.242.51]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABG51891; Mon, 22 Apr 2002 10:15:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20020422094230.038f1b78@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Mao From: Jeff Learman Subject: Re: [Isis-wg] IS-IS on UPSR ring Cc: isis-wg@spider.juniper.net In-Reply-To: <20020419233323.98158.qmail@web11604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 10:15:17 -0400 Laurence, This isn't really an IS-IS question, it's a SONET question. For SONET DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual fiber counter-directional rings are required. To the software, you must make it look like there is a bidirectional link between A and B, using the clockwise ring for transmit and the counterclockwise ring for receive. For single-fiber rings, you would need a proprietary solution. You could try something like Token Ring at the link layer and make the ring look like a TR broadcast LAN. Regards, Jeff At 07:33 PM 4/19/2002, Lawrence Mao wrote: >Hi all, > >If the IS-IS needs to be supported on a SONET >UPSR ring, throught its DCC channel (note that >the ring is uni-directional), say, if I have 4 >nodes on a ring: > > A --> B --> C --> D - > ^ | > |-------------------- > >what kind of modifications need to be made in >order to let the protocol work properly (note >all interfaces are p2p type)? > >2nd question is, if the interface is unnumbered, >how is its routing table generated? Use routerID? > >Thanks, >-- >Lawrence > >__________________________________________________ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://taxes.yahoo.com/ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 10:31:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26922 for ; Mon, 22 Apr 2002 10:31:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEGht05836; Mon, 22 Apr 2002 07:16:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEDat05808 for ; Mon, 22 Apr 2002 07:13:36 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MEQYx29750; Mon, 22 Apr 2002 16:26:34 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MEPqI02083; Mon, 22 Apr 2002 15:25:53 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 15:26:32 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB63A@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Jeff Learman'" , Lawrence Mao Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] IS-IS on UPSR ring MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA09.B04306F4" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 15:26:27 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA09.B04306F4 Content-Type: text/plain; charset="iso-8859-1" Specifically (according to G.7712):- IP-only Integrated IS-IS NEs use PPP over HDLC in DCC. OSI-only IS-IS NEs use LAPD over DCC. Dual Integrated IS-IS NEs need a switchable (PPP or LAPD) data link layer. Philip > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: 22 April 2002 15:15 > To: Lawrence Mao > Cc: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] IS-IS on UPSR ring > > > > Laurence, > > This isn't really an IS-IS question, it's a SONET question. For SONET > DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual > fiber counter-directional rings are required. To the > software, you must > make it look like there is a bidirectional link between A and B, using > the clockwise ring for transmit and the counterclockwise ring for > receive. > > For single-fiber rings, you would need a proprietary solution. You > could try something like Token Ring at the link layer and make the > ring look like a TR broadcast LAN. > > Regards, > Jeff > > At 07:33 PM 4/19/2002, Lawrence Mao wrote: > >Hi all, > > > >If the IS-IS needs to be supported on a SONET > >UPSR ring, throught its DCC channel (note that > >the ring is uni-directional), say, if I have 4 > >nodes on a ring: > > > > A --> B --> C --> D - > > ^ | > > |-------------------- > > > >what kind of modifications need to be made in > >order to let the protocol work properly (note > >all interfaces are p2p type)? > > > >2nd question is, if the interface is unnumbered, > >how is its routing table generated? Use routerID? > > > >Thanks, > >-- > >Lawrence > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Tax Center - online filing with TurboTax > >http://taxes.yahoo.com/ > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01C1EA09.B04306F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] IS-IS on UPSR ring

Specifically (according to G.7712):-

IP-only Integrated IS-IS NEs use PPP over HDLC in = DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or = LAPD) data link layer.

Philip

> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]=
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR = ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a = SONET question.  For SONET
> DCC, you run IS-IS over LAP-B (or possibly = PPP).  In either case, dual
> fiber counter-directional rings are = required.  To the
> software, you must
> make it look like there is a bidirectional link = between A and B, using
> the clockwise ring for transmit and the = counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a = proprietary solution.  You
> could try something like Token Ring at the link = layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao = wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a = SONET
> >UPSR ring, throught its DCC channel (note = that
> >the ring is uni-directional), say, if I = have 4
> >nodes on a ring:
> >
> >    A --> B --> C = --> D -
> >    = ^            = ;        |
> >    = |--------------------
> >
> >what kind of modifications need to be made = in
> >order to let the protocol work properly = (note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is = unnumbered,
> >how is its routing table generated? Use = routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> = >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with = TurboTax
> >http://taxes.yahoo.com/
> = >_______________________________________________
> >Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg=
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

------_=_NextPart_001_01C1EA09.B04306F4-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 10:37:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27226 for ; Mon, 22 Apr 2002 10:37:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEMSt05875; Mon, 22 Apr 2002 07:22:28 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEFZt05824 for ; Mon, 22 Apr 2002 07:15:35 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id HAA23847; Mon, 22 Apr 2002 07:28:41 -0700 (PDT) From: Mike Truskowski Message-Id: <200204221428.HAA23847@wells.cisco.com> Subject: Re: [Isis-wg] IS-IS on UPSR ring To: jlearman@cisco.com Cc: lqmao@yahoo.com, isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020422094230.038f1b78@dingdong.cisco.com> from Jeff Learman at Apr "22," 2002 "10:15:17" am X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 07:28:41 -0700 (PDT) Content-Transfer-Encoding: 7bit Lawrence, Who do you work for? Mike > > Laurence, > > This isn't really an IS-IS question, it's a SONET question. For SONET > DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual > fiber counter-directional rings are required. To the software, you must > make it look like there is a bidirectional link between A and B, using > the clockwise ring for transmit and the counterclockwise ring for > receive. > > For single-fiber rings, you would need a proprietary solution. You > could try something like Token Ring at the link layer and make the > ring look like a TR broadcast LAN. > > Regards, > Jeff > > At 07:33 PM 4/19/2002, Lawrence Mao wrote: > >Hi all, > > > >If the IS-IS needs to be supported on a SONET > >UPSR ring, throught its DCC channel (note that > >the ring is uni-directional), say, if I have 4 > >nodes on a ring: > > > > A --> B --> C --> D - > > ^ | > > |-------------------- > > > >what kind of modifications need to be made in > >order to let the protocol work properly (note > >all interfaces are p2p type)? > > > >2nd question is, if the interface is unnumbered, > >how is its routing table generated? Use routerID? > > > >Thanks, > >-- > >Lawrence > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Tax Center - online filing with TurboTax > >http://taxes.yahoo.com/ > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 10:55:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28051 for ; Mon, 22 Apr 2002 10:55:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEf1t05985; Mon, 22 Apr 2002 07:41:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MEe4t05973 for ; Mon, 22 Apr 2002 07:40:04 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id HAA17224; Mon, 22 Apr 2002 07:52:28 -0700 (PDT) From: Mike Truskowski Message-Id: <200204221452.HAA17224@wells.cisco.com> Subject: Re: [Isis-wg] IS-IS on UPSR ring To: christi@nortelnetworks.com Cc: jlearman@cisco.com, lqmao@yahoo.com, isis-wg@spider.juniper.net In-Reply-To: <4103264BC8D3D51180B7002048400C454FB63A@zhard0jd.europe.nortel.com> from Philip Christian at Apr "22," 2002 "03:26:27" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1019487148-21486-0_ Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 07:52:28 -0700 (PDT) --ELM1019487148-21486-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit G.7712 also states that OSPF is an option. :-) Mike --ELM1019487148-21486-0_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Description: /tmp/BAAa21486 Content-Transfer-Encoding: 7bit Specifically (according to G.7712):- IP-only Integrated IS-IS NEs use PPP over HDLC in DCC. OSI-only IS-IS NEs use LAPD over DCC. Dual Integrated IS-IS NEs need a switchable (PPP or LAPD) data link layer. Philip > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: 22 April 2002 15:15 > To: Lawrence Mao > Cc: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] IS-IS on UPSR ring > > > > Laurence, > > This isn't really an IS-IS question, it's a SONET question. For SONET > DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual > fiber counter-directional rings are required. To the > software, you must > make it look like there is a bidirectional link between A and B, using > the clockwise ring for transmit and the counterclockwise ring for > receive. > > For single-fiber rings, you would need a proprietary solution. You > could try something like Token Ring at the link layer and make the > ring look like a TR broadcast LAN. > > Regards, > Jeff > > At 07:33 PM 4/19/2002, Lawrence Mao wrote: > >Hi all, > > > >If the IS-IS needs to be supported on a SONET > >UPSR ring, throught its DCC channel (note that > >the ring is uni-directional), say, if I have 4 > >nodes on a ring: > > > > A --> B --> C --> D - > > ^ | > > |-------------------- > > > >what kind of modifications need to be made in > >order to let the protocol work properly (note > >all interfaces are p2p type)? > > > >2nd question is, if the interface is unnumbered, > >how is its routing table generated? Use routerID? > > > >Thanks, > >-- > >Lawrence > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Tax Center - online filing with TurboTax > >http://taxes.yahoo.com/ > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > --ELM1019487148-21486-0_ Content-Type: text/html; charset="iso-8859-1" Content-Disposition: inline Content-Description: /tmp/CAAa21486 Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] IS-IS on UPSR ring

Specifically (according to G.7712):-

IP-only Integrated IS-IS NEs use PPP over HDLC in = DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or = LAPD) data link layer.

Philip

> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]=
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR = ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a = SONET question.  For SONET
> DCC, you run IS-IS over LAP-B (or possibly = PPP).  In either case, dual
> fiber counter-directional rings are = required.  To the
> software, you must
> make it look like there is a bidirectional link = between A and B, using
> the clockwise ring for transmit and the = counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a = proprietary solution.  You
> could try something like Token Ring at the link = layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao = wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a = SONET
> >UPSR ring, throught its DCC channel (note = that
> >the ring is uni-directional), say, if I = have 4
> >nodes on a ring:
> >
> >    A --> B --> C = --> D -
> >    = ^            = ;        |
> >    = |--------------------
> >
> >what kind of modifications need to be made = in
> >order to let the protocol work properly = (note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is = unnumbered,
> >how is its routing table generated? Use = routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> = >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with = TurboTax
> >http://taxes.yahoo.com/
> = >_______________________________________________
> >Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg=
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

--ELM1019487148-21486-0_-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 13:56:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05315 for ; Mon, 22 Apr 2002 13:56:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MHf1t06760; Mon, 22 Apr 2002 10:41:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MHeet06748 for ; Mon, 22 Apr 2002 10:40:40 -0700 (PDT) (envelope-from nsheth@juniper.net) Received: from juniper.net (bsd4-build4.juniper.net [172.17.28.65]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3MHrgT54922; Mon, 22 Apr 2002 10:53:42 -0700 (PDT) (envelope-from nsheth@juniper.net) Message-ID: <3CC44E26.4090909@juniper.net> From: Nischal Sheth Organization: Juniper Networks, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Naiming Shen CC: Dave Katz , mshand@cisco.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] a few comments on ietf restart isis draft References: <20020420192403.C6FB64F41B9@prattle.redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 10:53:42 -0700 Content-Transfer-Encoding: 7bit Naiming Shen wrote: > ] (2) page 4, the 2nd paragraph, > ] > ] "a) DO NOT refresh the timer on the adjacency, ..." > ] > ] I have big problem with this. The receiving router has a good > ] adjacency to the neighbor which just restarted, this neighbor > ] asks for help. The restarting neighbor sent out an IIH > ] containing RR bit set, and also has its "holding time" value > ] in this IIH. Why should the receiving router not to refresh the > ] timer using the latest "holding time" value in this re-start IIH? > ] > ] Nischal came up with a variant of this which accomplishes both goals-- > ] accept the hold time from the IIH that causes you to become a restart > ] helper, and then don't refresh after that. > > why not refresh after that? I think we should always refresh. Well, > it's an implementation issue also, then I don't go into that. > Naiming, Not refreshing after the first time can help cover two possible corner cases: o the restarting router crashes again while coming up o the hello with the restart ACK gets lost I agree that it's much better to refresh the timer on the adjacency than not to (like the draft says currently). Whether to do it the first time or every time is up to the implementation. Thanks, Nischal. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 22 16:48:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12457 for ; Mon, 22 Apr 2002 16:48:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3MKX1t07614; Mon, 22 Apr 2002 13:33:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g3MKWHt07602 for ; Mon, 22 Apr 2002 13:32:17 -0700 (PDT) (envelope-from lqmao@yahoo.com) Message-ID: <20020422204527.79867.qmail@web11607.mail.yahoo.com> Received: from [63.98.44.82] by web11607.mail.yahoo.com via HTTP; Mon, 22 Apr 2002 13:45:27 PDT From: Lawrence Mao To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] IS-IS on UPSR ring Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 13:45:27 -0700 (PDT) Thanks for all the replies. I understand the approach of Token Ring at layer 2 for single-fiber rings. But what if we could not change the code in the link layer (PPP or LAPD), and modifying the IS-IS code would be the only way to do? Then I am wondering what the minimum code changes are needed, areas such as neighbor adjacency, PSNP ACK, SPF calculation, etc.? Thanks, -- Lawrence ------------------------------------------------------ Laurence, This isn't really an IS-IS question, it's a SONET question. For SONET DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual fiber counter-directional rings are required. To the software, you must make it look like there is a bidirectional link between A and B, using the clockwise ring for transmit and the counterclockwise ring for receive. For single-fiber rings, you would need a proprietary solution. You could try something like Token Ring at the link layer and make the ring look like a TR broadcast LAN. Regards, Jeff At 07:33 PM 4/19/2002, Lawrence Mao wrote: >Hi all, > >If the IS-IS needs to be supported on a SONET >UPSR ring, throught its DCC channel (note that >the ring is uni-directional), say, if I have 4 >nodes on a ring: > > A --> B --> C --> D - > ^ | > |-------------------- > >what kind of modifications need to be made in >order to let the protocol work properly (note >all interfaces are p2p type)? > >2nd question is, if the interface is unnumbered, >how is its routing table generated? Use routerID? > >Thanks, >-- >Lawrence __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 00:51:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27708 for ; Tue, 23 Apr 2002 00:51:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3N4a1t09543; Mon, 22 Apr 2002 21:36:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3N4Z5t09530 for ; Mon, 22 Apr 2002 21:35:05 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B06A5CAB7A; Mon, 22 Apr 2002 21:48:18 -0700 (PDT) To: Nischal Sheth Cc: Naiming Shen , Dave Katz , mshand@cisco.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] a few comments on ietf restart isis draft In-reply-to: Mail from Nischal Sheth dated Mon, 22 Apr 2002 10:53:42 PDT <3CC44E26.4090909@juniper.net> From: Naiming Shen Message-Id: <20020423044818.B06A5CAB7A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Apr 2002 21:48:18 -0700 Hi Nischal, I agree that "first time" or "every time" is an implementation detail. Here I just want to cover the two corner cases for someone wants to implement "every time" refresh. ] o the restarting router crashes again while coming up If we want to prevent a neighbor repeated restart again and again, we can put a counter for the restart adjacency, if exceeds the limit, tear down the adjacency. So even if we refresh the holding time for every re-start IIH, thats ok. The advantage of refreshing every time in this case is that, it gives every restart the same chance. Why does anyone need this? for some implementation, if a router tries a new version of software 3 times and all crashes, it can bring back the older version of software. In this case, the 4th restart will still have enough time to succeed. Just some implementation detail. ] o the hello with the restart ACK gets lost If the restart ACK gets lost, or if the restart IIH gets lost, according to the draft, we'll resend the restart IIH again. If they are lost again, .... So basically the same issue as the first case, do we want to deduct time from each restart IIH, or do we want to give each the same chance. Thus it's the same implementation detail. I personally don't even think we should resend again if they got lost. thanks. ] ] I agree that it's much better to refresh the timer on the adjacency than ] not to (like the draft says currently). Whether to do it the first time ] or every time is up to the implementation. ] ] Thanks, ] Nischal. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 05:18:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09799 for ; Tue, 23 Apr 2002 05:18:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3N8s0t10604; Tue, 23 Apr 2002 01:54:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3N8rOt10592 for ; Tue, 23 Apr 2002 01:53:24 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR27ZX>; Tue, 23 Apr 2002 05:06:33 -0400 Message-ID: From: "Manral, Vishwas" To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 05:06:28 -0400 Hi Amir/Stefano/Mike, I read thru ur draft and had an alternate idea in mind. I wanted to know what you thought of it. Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - The idea is to have a new TLV, which tells the actual LSP number. The LSP number in the psudonode-id is not used. The changes required are minimum. We anyway scan thru TLV's for authentication information, we can find the LSP number TLV then. We instead use this TLV. To migrate to such a method all we need to do is to, use same LSP numbers in the header and the TLV, and once all routers recognize the TLV, we actually can use different numbers. This does not create any backward compatibility issues and so we dont need two methods. In this case we do not need to worry about Attached bit, Partition repair bit or change to SPF calculations etc. The solution also seems a logical extension, to the constraint caused by 8 bit LSP number value. Rather than a solution that has multiple system id's which is like fooling the IS to believe all the systems are the same. Thanks, Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 07:31:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12738 for ; Tue, 23 Apr 2002 07:31:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NBFht11780; Tue, 23 Apr 2002 04:15:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NBBut11748 for ; Tue, 23 Apr 2002 04:11:56 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3NBPAn39438 for ; Tue, 23 Apr 2002 04:25:11 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 04:11:28 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11739; Tue, 23 Apr 2002 07:13:22 -0400 (EDT) Message-Id: <200204231113.HAA11739@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 23 Apr 2002 11:11:29.0000 (UTC) FILETIME=[9DC60680:01C1EAB7] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-10.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 07:13:22 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter et al. Filename : draft-ietf-isis-gmpls-extensions-10.txt Pages : 11 Date : 22-Apr-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-10.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: <20020422135137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135137.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 08:52:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15290 for ; Tue, 23 Apr 2002 08:51:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NCait12179; Tue, 23 Apr 2002 05:36:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NCUlt12143 for ; Tue, 23 Apr 2002 05:30:48 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp27.cisco.com [144.254.108.94]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA27360; Tue, 23 Apr 2002 13:43:30 +0100 (BST) Message-Id: <4.3.2.7.2.20020423133001.00b71660@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: mike shand Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 13:43:28 +0100 I'm not sure I fully understand this proposal. I assume that when you actually start using extended numbers you still need to invent additional system ID's for the extra "fragments" so that the update process can distinguish them. In which case it is semantically identical to the current scheme. Or are you proposing changing the update process so that it looks at the new TLV? I guess that must be what you have in mind. This has fairly serious consequences if you have migrated to extended numbers, but you then introduce a router which doesn't understand the new update process. I thought we had already considered and rejected solutions of this type. Mike At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: >Hi Amir/Stefano/Mike, > >I read thru ur draft and had an alternate idea in mind. I wanted to know >what you thought of it. > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > >The idea is to have a new TLV, which tells the actual LSP number. The LSP >number in the psudonode-id is not used. The changes required are minimum. We >anyway scan thru TLV's for authentication information, we can find the LSP >number TLV then. We instead use this TLV. > >To migrate to such a method all we need to do is to, use same LSP numbers in >the header and the TLV, and once all routers recognize the TLV, we actually >can use different numbers. This does not create any backward compatibility >issues and so we dont need two methods. In this case we do not need to worry >about Attached bit, Partition repair bit or change to SPF calculations etc. >The solution also seems a logical extension, to the constraint caused by 8 >bit LSP number value. Rather than a solution that has multiple system id's >which is like fooling the IS to believe all the systems are the same. > >Thanks, >Vishwas >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 11:25:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22867 for ; Tue, 23 Apr 2002 11:25:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NF91t12873; Tue, 23 Apr 2002 08:09:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NF8Mt12861 for ; Tue, 23 Apr 2002 08:08:22 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR28Q4>; Tue, 23 Apr 2002 11:21:32 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 11:21:28 -0400 Hi Mike, Thanks for the reply. I do not understand if we have migrated to a bigger LSp number, why we would bring in a router that still uses a smaller LSP number, even when we know it could create problems. This problem can occur in all cases of migration a) to domain wide b) wide metrics I do not see why we should introduce a two pronged method to do something which we can do pretty easily with just a TLV change, when similar approaches have been taken for other cases. Even in domain wide if a router came in which did not use external reachability in cases of L1 area the same problem would occur. I do not find the reason convincing enough to be rejected. ;-) Thanks, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Tuesday, April 23, 2002 6:13 PM To: Manral, Vishwas Cc: 'isis-wg@spider.juniper.net' Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt I'm not sure I fully understand this proposal. I assume that when you actually start using extended numbers you still need to invent additional system ID's for the extra "fragments" so that the update process can distinguish them. In which case it is semantically identical to the current scheme. Or are you proposing changing the update process so that it looks at the new TLV? I guess that must be what you have in mind. This has fairly serious consequences if you have migrated to extended numbers, but you then introduce a router which doesn't understand the new update process. I thought we had already considered and rejected solutions of this type. Mike At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: >Hi Amir/Stefano/Mike, > >I read thru ur draft and had an alternate idea in mind. I wanted to know >what you thought of it. > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > >The idea is to have a new TLV, which tells the actual LSP number. The LSP >number in the psudonode-id is not used. The changes required are minimum. We >anyway scan thru TLV's for authentication information, we can find the LSP >number TLV then. We instead use this TLV. > >To migrate to such a method all we need to do is to, use same LSP numbers in >the header and the TLV, and once all routers recognize the TLV, we actually >can use different numbers. This does not create any backward compatibility >issues and so we dont need two methods. In this case we do not need to worry >about Attached bit, Partition repair bit or change to SPF calculations etc. >The solution also seems a logical extension, to the constraint caused by 8 >bit LSP number value. Rather than a solution that has multiple system id's >which is like fooling the IS to believe all the systems are the same. > >Thanks, >Vishwas >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 19:49:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10012 for ; Tue, 23 Apr 2002 19:49:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NNX1t15065; Tue, 23 Apr 2002 16:33:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3NNWbt15053 for ; Tue, 23 Apr 2002 16:32:37 -0700 (PDT) (envelope-from Radia.Perlman@Sun.COM) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3NNjtn60017 for ; Tue, 23 Apr 2002 16:45:55 -0700 (PDT) X-JNPR-Received-From: outside Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 16:43:57 -0700 Received: from bcn.East.Sun.COM ([129.148.75.4]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09595 for ; Tue, 23 Apr 2002 16:45:55 -0700 (PDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id TAA10336 for ; Tue, 23 Apr 2002 19:45:55 -0400 (EDT) Message-Id: <200204232345.TAA10336@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZimGMX0NsrxNCRQISgSmEQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc X-OriginalArrivalTime: 23 Apr 2002 23:43:57.0671 (UTC) FILETIME=[BC7A7F70:01C1EB20] Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 19:45:53 -0400 (EDT) Assuming I'm not misreading the spec, it looks like the assumption is that there are the following secrets: a) an area-wide secret b) a link secret, for each link c) a domain secret And it looks like Hellos use the link secret, LSPs and SNPs use the area-wide secret (unless they are level 2 in which case they use the domain secret). A few questions: 1) I'd assume that SNPs should use the link secret, since they are not forwarded 2) I remember IS-IS having a set of acceptable receive secrets, and a single transmit password, so that secret rollover wouldn't be a problem. This draft seems to imply there's only a single one. 3) Shouldn't there be a separate layer 1 and layer 2 link secret? (Again, I think I remember that from DECnet). Also, it's not traditional for an author to thank himself in the acknowledgements :-) Radia _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 21:40:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12186 for ; Tue, 23 Apr 2002 21:40:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3O1Pht15679; Tue, 23 Apr 2002 18:25:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3O1Lxt15653 for ; Tue, 23 Apr 2002 18:21:59 -0700 (PDT) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3O1ZH646646 for ; Tue, 23 Apr 2002 18:35:18 -0700 (PDT) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 17:50:56 -0700 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz1.procket.com (Postfix) with ESMTP id 9FEBE23C24; Tue, 23 Apr 2002 17:41:33 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g3O0qrvM026992; Tue, 23 Apr 2002 17:52:53 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g3O0qrRF019121; Tue, 23 Apr 2002 17:52:53 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15558.485.501119.780417@alpha-tli.procket.com> To: Radia Perlman - Boston Center for Networking Cc: isis-wg@juniper.net Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt In-Reply-To: <200204232345.TAA10336@bcn.East.Sun.COM> References: <200204232345.TAA10336@bcn.East.Sun.COM> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 24 Apr 2002 00:50:56.0250 (UTC) FILETIME=[17BCFDA0:01C1EB2A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 17:52:53 -0700 Content-Transfer-Encoding: 7bit | 1) I'd assume that SNPs should use the link secret, since they are | not forwarded Yes, but they can be replicated on multiple links. This simplifies implementation. | 2) I remember IS-IS having a set of acceptable receive secrets, | and a single transmit password, so that secret rollover wouldn't | be a problem. This draft seems to imply there's only a single one. That is certainly an implementation option. | 3) Shouldn't there be a separate layer 1 and layer 2 link secret? | (Again, I think I remember that from DECnet). What is gained from this? [Side question: what is gained from multiple secrets anyhow?] I know of no installations where someone would allow an L1 adjacency but not an L2. Seems like it could be simplified... Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 23 22:49:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14144 for ; Tue, 23 Apr 2002 22:49:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3O2Y1t16045; Tue, 23 Apr 2002 19:34:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3O2X6t16033 for ; Tue, 23 Apr 2002 19:33:06 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3O2kPn63811 for ; Tue, 23 Apr 2002 19:46:25 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 23 Apr 2002 19:32:47 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA21650; Tue, 23 Apr 2002 19:34:44 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G8NHQ3>; Tue, 23 Apr 2002 19:34:44 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F97B@avalon.pluris.com> From: Les Ginsberg To: "'Radia Perlman - Boston Center for Networking'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Apr 2002 02:32:47.0671 (UTC) FILETIME=[526DD470:01C1EB38] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Apr 2002 19:34:41 -0700 > 1) I'd assume that SNPs should use the link secret, since they are > not forwarded > SNPs use area/domain passwords as specified in ISO 10589 7.3.15.3a. (and other places) > 3) Shouldn't there be a separate layer 1 and layer 2 link secret? > (Again, I think I remember that from DECnet). > ISO 10589 does not mention separate authentication info for Level1/Level2, but some implementations support this. Les _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 10:07:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07876 for ; Wed, 24 Apr 2002 10:07:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ODp2t19341; Wed, 24 Apr 2002 06:51:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ODoRt19329 for ; Wed, 24 Apr 2002 06:50:28 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp27.cisco.com [144.254.108.94]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14547; Wed, 24 Apr 2002 15:03:42 +0100 (BST) Message-Id: <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Naiming Shen From: mike shand Cc: naiming@redback.com, isis-wg@spider.juniper.net In-Reply-To: <20020420065230.CDC0039B5AF@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Re: a few comments on ietf restart isis draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 14:53:26 +0100 At 23:52 19/04/2002 -0700, Naiming Shen wrote: >Hi Mike, > >I have a few comments on draft-ietf-isis-restart-00.txt, I apologize >for the late discussion. It was in my "stuff I gotta read" folder >for too long (something just learned from Jeff) ;-) > > (1) TLV code [TBD] > > seems we have a code for this now. Yes. That needs to go in. > (2) page 4, the 2nd paragraph, > > "a) DO NOT refresh the timer on the adjacency, ..." > > I have big problem with this. The receiving router has a good > adjacency to the neighbor which just restarted, this neighbor > asks for help. The restarting neighbor sent out an IIH > containing RR bit set, and also has its "holding time" value > in this IIH. Why should the receiving router not to refresh the > timer using the latest "holding time" value in this re-start IIH? > > I think in this case, the receiving router is "lucky" enough to > get an IIH(with RR bit) from the restarting router before it times > this adjacency out, so the receiving router should do everything > to help the neighbor to complete the restart process. > > for example: the receiving router only has 1 second left on this > adjacency, and received the RR bit set IIH on this adjacency. This > IIH has the "holding time" of 30 seconds. If it wants to help > the neighbor to complete a good restart, should the receiving > router times out this adjacency in 1 second, or should the receiving > router holds on this adjacency for another 30 seconds? I would > definitely go for the later. > > The only "harm" I can see if updating the timer is that, if the > restart router after sending out the re-start IIHs, then crashed > again and never come back. If this happens, then the convergence > is a little slow, but this may not affect the forwarding and its > a very rare case. > > Yes, the vendors should make the restart come back way before the > neighbors holding time expires, but it may not always be so easy; > Yes, the normal holding time can be configured long enough so it > always handles whatever time restart takes, but that seems going > the opposite direction from IGP milli-second convergence. > > I would change "DO NOT" into "MUST" here. I think, given the various scenarios, we need a bit of flexibility here. My intent was that the whole thing was "fail safe". i.e. if the restarting router didn't come back up properly, the neighbors would drop their adjacencies as if it had just plain failed. I didn't want the restarting to delay the normal recovery. However, I understand that some implementations may not be able to get back up within this time, especially for short hello times, and that some measure of "hello I'm back, could you just give me a little extra time to get my act together" would be helpful. I like Nischal's suggestion here. > 3) page 4, paragraph 3 and 4 > > Probably need to say something explicitly about the ordering of > those packets. If we have IIH(with RA bit), CSNPs and LSPs to be > sent to help the neighbor restart, we need to make sure the IIH goes > out first. Otherwise the CSNPs or LSPs can be dropped by > the re-starting neighbor since it does not have an adjacency yet. > "without waiting for any currently running timer interval to expire" > may refer to the same idea, but it should be spelled out. Yes. That was the idea. You need to get the IIH out first, but saying so explicitly wouldn't hurt. > 4) page 4, paragraph 5 > > "i.e. if there was no adjacency" > > Should add "or the adjacency is not in the "UP" state". Yes. Agreed. > 5) page 4, last two paragraphs > > "contains an empty ..." and "option with state "Down" and with empty .." > > Probably those two sentences should be removed. Because on page 4 the > first paragraph says: > > "irrespective of the other contents of the "Intermediate System > Neighbors" option (LAN circuits), or the "Point-to-Point Adjacency > State" option"... > > Which means, as long as the RR bit is set in this re-start tlv, > we don't care about the ISN tlv is empty or NOT empty and we don't > care about what state this IIH has. Which is good. > > I'm not just nit-picking on language here, basically this RR bit > is a mechanism for IS-IS to re-acquire LSPs from neighbors. It can > be used for some other applications other than graceful restart. > In those cases, we don't want to send out empty ISN TLVs or in > a "Down" state. Also we don't want the neighbors to ignore my > "holding time" either;-) (see the comment #2). Yes. I agree. I was being over prescriptive. I think I was just pointing out that you didn't need to "know" that information or include it. But as you say, there is no reason why you shouldn't if you want to. > 6) levels of IIH with RR bit set > > The draft probably should say clearly about the levels: > > on the LAN, if both levels are active on the interface, it > should send out two IIHs with the RR bit set, one for each > level. The receiving router may respond with two IIHs with RA > bit, one for each level where the adjacencies are in UP state. > a) b) and c) on page 4 is for each level. on p2p intf, only send > one IIH, but the receiving router still needs to check for > both levels base on the adjacency usage to send out csnps and lsps. Yes. I think someone else already pointed this out. > 7) page 3, last paragraph > > This comment is closely related to comment #2. > > Assume we DO(opposite from the current draft) update the adjacency > timer by the receiving router, then this "Remaining Time" field is > no use here. This value set by the Receiving router would be the > same as the "holding time" value in the IIH the re-start router > just sent out. Thus this re-start TLV can use just one octet in > length. Yes. Of course the idea was to figure out how long you had been unconscious when you woke up, and hence how much time you still had left. You are right that if we refresh when we come back up we don't need this. > The T3 is the minimum value of all the IS-IS intf holding times. > And it can be figured out immediately without waiting for > neighbors to tell us. It is based on local configure settings. > > I think about this way: it's reasonable to expect all the interfaces > go through the similar amount of time to finish this re-start > job. But if we ask the neighbors NOT updating the timers on > the adjacencies, it will be very random. Some adjacencies will be > timed out in 1 second, some will be in 20 seconds, etc. It's much > better to ask them to time out me in, say 20 seconds, across > the board. "Since I'm back, give me another chance, and I know > my restart process takes xx seconds". Implementations can > even offer a config knob to send a different(base on the > local configuration size, network topology size and database size, > also the vendor implementation, those are all closely related > to the re-start time) holding time in this re-start IIH. > > T3 is the minimum of this "Remaining Time" right now. So if T3 > times out, all the normal IIHs are starting to go out on all > the interfaces, this means, if one adjacency has low timeout > from our neighbors, all our adjacencies may be affected during > the restart since they sees the incomplete ISN TLVs in normal IIHs. I think you've convinced me. Anyone think otherwise? > 8) page 4, paragraph 4 > > "excluding the transmitting router" > > An optimization would be, "excluding the transmitting router > and only include the routers on the LAN who had re-start > TLV in their IIHs". There maybe someone on the LAN running old > code, that router just happen to have the highest priority but > it can not help the restart neighbor with CSNP and LSPs. So > some router with new code should step in now since the information > is available. Good idea. Yes. > 9) page 5, first paragraph > > "On expiry of the timer T1, it is restarted and the IIH is > re-transmitted as above." > > I take it that, this is to avoid the first IIH packet got > lost, so let's retry. and have a maximum number of retry > mentioned in page 6. Yes. > I think we should not even retry. This graceful restart is > not meant to be bullet proof. If the IIHs happen to get lost, > we just have a bad day. This is also the same problem if you > have multiple neighbors on the same LAN. Your IIH can be lost > to one of the neighbors, but as soon as you receive from > other neighbors and complete the CSNPs, the T1 will be cancelled. > But you have no way to know, that one neighbor didn't > receive your re-start IIH, and it will reset the adjacency. > The current scheme does not cover that case, and I think its > not worth to have retries in general. Thus actually we don't > even need the T1. I'm not sure. I didn't like the idea that we may be stalled waiting for multiple retries, but OTOH it goes against the grain to design a protocol which "fails" on the loss of a single packet :-) I guess the question is how many times will we sit around waiting for a response when we will never get one, as opposed to the times when we genuinely loose a packet and this allows us to re-start when we otherwise wouldn't. Any other opinions? > 10) page 8, the 5th paragraph > > "are then flooded with the overload bit set to indicate that > the router's LSPDB is not yet synchronized" > > I would be very careful setting OL bit here. T3 times out just > means we are sending out normal IIHs, that should not affect > anything even we have not acquired all the LSPs from neighbors > or we haven't finished our SPF. > > The goal of this graceful restart is to do non-stop forwarding, > if we send out our LSPs with OL on, it's not non-stop forwarding > any more. Yes our SPF has not finished yet, so what's the hurry? > why not let it to finish? Its much better to delay sending out > our LSPs(assume topology has not changed during re-start) since > routers in the area has our old LSPs containing the same > information, than to send out LSPs immaturely with OL bit set. The point is that we have time that we are prepared to run headless. That time has expired. We may be generating all sorts of loops and confusion (or we may not of course - we don't know). What do we do? Continue to screw up the traffic, or admit defeat and take ourselves out? I suggest that the only honest thing to do is the latter. We COULD do this by dropping all our adjacencies and getting our neighbors to sends LSPs saying we had gone away. However it seems cleaner simply to set our overload bit. This is after all what we would expect to do if we were coming up without re-start and we we were using the OL bit in this way. However, it may be undesirable to actually insist on this behaviour. Maybe it should say that if you are following the setting the OL bit when you come up stuff, now would be a good time to do it. > Also in 4.3.1.1, "with the overload bit clear", just a simple > comment, some implementation/configurations couple this OL bit > with bgp convergence, and usually bgp "converge" takes longer > than the IGP lsp synchronization. Yes, absolutely. It shouldn't say turn it off it should say stop turning it on for this reason (or words to that effect). > 11) 3way hello state > > The draft suggested to send the re-start IIH, with RR bit set, > and 3way state in "Down" on the p2p interface. Assume the > neighbor sends back the IIH with "UP" state with RA bit set. > If we follow the 3way hello draft, we are in "Down", when > receives an "Up", the result state is still "Down". And this > is not good. We need to setup this adjacency to "Up" state > immediately because we need to receive and accept CSNPs and > LSPs over this link soon. So the draft needs to suggest the > re-starting router either sending out the re-start IIH with > "Init" or "Up" state, or specifying not to follow the 3way > hello state table in this case and bring the adjacency up > immediately. I think the former is better. To be honest, I've completely forgotten why I wanted to send it in down state. I agree absolutely that it needs to go straight into up on receipt of the reply (and I thought it said that somewhere, but I can't find it). So I guess what I thought was happening was the latter. If there is no problem with sending in init or up, then I wouldn't object, but I'm sure there was a good reason to avoid it. Maybe it will come back to me.... > 12) re-start router lsp acquiring and flooding optimization? > > If the re-start router has one hundred IS-IS interfaces, at > restart, it will receive 100 copies of the databases from > all the interfaces assume all the neighbors can help. We > also need to flooding all of them to the other 99 interfaces > 100 times. Um... 100 times? Why? Yes we flood the first copy we see of each LSP to all the other 99, but subsequent copies are just acked. > If we have a huge database, it can take a while;-) > I'm wondering if the re-starting router and all its neighbors > can periodically exchange a number of CSNP sets during this > synchronization process until the T3 expires on the re-starting > router, and until the neighbors sees a "normal" IIH from the > re-starting router. I'm not sure how much this helps. 'A' sends us a bunch of LSPs, and we flood them out to B through Z, which causes B through Z to clear SRMflags for those LSPs (and set SSNflags instead on a p2p). Or if we already receive it from (say B) we won't flood it - just set SSNflags back to A. It would help of course if we randomized the order of LSP transmission. 10589 says to do this on LANs for exactly this reason, but doesn't require it on p2p. I don't quite see how the extra CSNPs help. Unless you are saying you can get a set of CSNPs out BEFORE you actually flood. Or you could just start up on a few interfaces to begin with, and get the bulk of LSPs over them, then turn on the rest and just get any remaining LSPs. Of course you have to choose the "right" few:-) I'm not sure whether these sort of optimizations need to be spelled out in the spec. There is some considerable scope for individual implementations ingenuity within the basic framework here. I don't think we want to over-constrain. > This way, the neighbors may not need to > send some redundant lsps, and the re-starting router may not > need to do unnecessary lsp flooding. > > >thanks. >- Naiming Thanks for some good comments. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 10:13:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08343 for ; Wed, 24 Apr 2002 10:13:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ODwlt19413; Wed, 24 Apr 2002 06:58:47 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ODsbt19356 for ; Wed, 24 Apr 2002 06:54:37 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR20R2>; Wed, 24 Apr 2002 10:07:54 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 10:07:47 -0400 Hi folks, As I have not got the reply to my mail, I will try and restate(I guess I wasn't clear) what the proposal is. The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit LSP number. The new TLV is propagated in all LSP's and overrides the LSP Number field in the header. To migrate to this scheme, as long as all the routers in the network do not support the new TLV, we use the same value in LSP number field in the header as well as the TLV. Once all the routers in the network support the new TLV, we can actually use the value of the LSP number TLV and ignore the LSP number field in the header. The solution in this scheme seems to be a logical extension to the limit caused by an 8 bit LSP number field, using a 32 bit sequence number, rather than the scheme where we need multiple system id's and then equating the ID's. The advantages of the scheme relative to the other scheme is: - a) We use a simple migration scheme rather than a two step highly complex scheme. b) We need not worry about any change to routing table calculations. c) No taking care of attached bit. d) No taking care of partition bit. e) We need not worry about which links use what system id(as in the other scheme) and hence a lot of configuration. f) The amount of code changes are minimal. Regarding Mike's comment(I hope I got it right, Mike?) what happens when a new router that does not support the functionality comes up. Although the assumption with the other drafts like domain-wide and wide metrics is that once we migrate to a scheme, we will not try and bother about the older scheme, the same problem would occur in the other draft too if a new router came up after we had migrated to method 2, and someone did not understand the ISIS Alias TLV described there. Routing loops could very easily occur there. Any comments/criticism invited. Thanks a lot, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@netplane.com] Sent: Tuesday, April 23, 2002 8:51 PM To: 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Hi Mike, Thanks for the reply. I do not understand if we have migrated to a bigger LSp number, why we would bring in a router that still uses a smaller LSP number, even when we know it could create problems. This problem can occur in all cases of migration a) to domain wide b) wide metrics I do not see why we should introduce a two pronged method to do something which we can do pretty easily with just a TLV change, when similar approaches have been taken for other cases. Even in domain wide if a router came in which did not use external reachability in cases of L1 area the same problem would occur. I do not find the reason convincing enough to be rejected. ;-) Thanks, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Tuesday, April 23, 2002 6:13 PM To: Manral, Vishwas Cc: 'isis-wg@spider.juniper.net' Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt I'm not sure I fully understand this proposal. I assume that when you actually start using extended numbers you still need to invent additional system ID's for the extra "fragments" so that the update process can distinguish them. In which case it is semantically identical to the current scheme. Or are you proposing changing the update process so that it looks at the new TLV? I guess that must be what you have in mind. This has fairly serious consequences if you have migrated to extended numbers, but you then introduce a router which doesn't understand the new update process. I thought we had already considered and rejected solutions of this type. Mike At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: >Hi Amir/Stefano/Mike, > >I read thru ur draft and had an alternate idea in mind. I wanted to know >what you thought of it. > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > >The idea is to have a new TLV, which tells the actual LSP number. The LSP >number in the psudonode-id is not used. The changes required are minimum. We >anyway scan thru TLV's for authentication information, we can find the LSP >number TLV then. We instead use this TLV. > >To migrate to such a method all we need to do is to, use same LSP numbers in >the header and the TLV, and once all routers recognize the TLV, we actually >can use different numbers. This does not create any backward compatibility >issues and so we dont need two methods. In this case we do not need to worry >about Attached bit, Partition repair bit or change to SPF calculations etc. >The solution also seems a logical extension, to the constraint caused by 8 >bit LSP number value. Rather than a solution that has multiple system id's >which is like fooling the IS to believe all the systems are the same. > >Thanks, >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 10:32:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09804 for ; Wed, 24 Apr 2002 10:32:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OEGht19533; Wed, 24 Apr 2002 07:16:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OECgt19502 for ; Wed, 24 Apr 2002 07:12:42 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp27.cisco.com [144.254.108.94]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA15367; Wed, 24 Apr 2002 15:25:31 +0100 (BST) Message-Id: <4.3.2.7.2.20020424151507.041004a8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: mike shand Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 15:25:29 +0100 At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: >Hi folks, > >As I have not got the reply to my mail, I will try and restate(I guess I >wasn't clear) what the proposal is. > >The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit >LSP number. The new TLV is propagated in all LSP's and overrides the LSP >Number field in the header. > >To migrate to this scheme, as long as all the routers in the network do not >support the new TLV, we use the same value in LSP number field in the header >as well as the TLV. Once all the routers in the network support the new TLV, >we can actually use the value of the LSP number TLV and ignore the LSP >number field in the header. > >The solution in this scheme seems to be a logical extension to the limit >caused by an 8 bit LSP number field, using a 32 bit sequence number, rather >than the scheme where we need multiple system id's and then equating the >ID's. > >The advantages of the scheme relative to the other scheme is: - > >a) We use a simple migration scheme rather than a two step highly complex >scheme. >b) We need not worry about any change to routing table calculations. >c) No taking care of attached bit. >d) No taking care of partition bit. >e) We need not worry about which links use what system id(as in the other >scheme) and hence a lot of configuration. >f) The amount of code changes are minimal. > >Regarding Mike's comment(I hope I got it right, Mike?) what happens when a >new router that does not support the functionality comes up. Although the >assumption with the other drafts like domain-wide and wide metrics is that >once we migrate to a scheme, we will not try and bother about the older >scheme, the same problem would occur in the other draft too if a new router >came up after we had migrated to method 2, and someone did not understand >the ISIS Alias TLV described there. Routing loops could very easily occur >there. Where do you put the extended numbers in xSNPs? Or are you proposing a new "extended" LSP entry TLV? What do you do for migration? send both? Even if you do this, if you have a router which doesn't understand the new stuff and you are using the extended number space, you will get perpetual re-transmission if you have two LSPs with the same "natural" number but different extended numbers sent to a non-participating router. It will only ACK one of them. et.c etc. Mike >Any comments/criticism invited. > >Thanks a lot, >Vishwas > >-----Original Message----- >From: Manral, Vishwas [mailto:VishwasM@netplane.com] >Sent: Tuesday, April 23, 2002 8:51 PM >To: 'mike shand' >Cc: 'isis-wg@spider.juniper.net' >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >Hi Mike, > >Thanks for the reply. > >I do not understand if we have migrated to a bigger LSp number, why we would >bring in a router that still uses a smaller LSP number, even when we know it >could create problems. This problem can occur in all cases of migration >a) to domain wide >b) wide metrics > >I do not see why we should introduce a two pronged method to do something >which we can do pretty easily with just a TLV change, when similar >approaches have been taken for other cases. Even in domain wide if a router >came in which did not use external reachability in cases of L1 area the same >problem would occur. I do not find the reason convincing enough to be >rejected. ;-) > >Thanks, >Vishwas > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Tuesday, April 23, 2002 6:13 PM >To: Manral, Vishwas >Cc: 'isis-wg@spider.juniper.net' >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >I'm not sure I fully understand this proposal. I assume that when you >actually start using extended numbers you still need to invent additional >system ID's for the extra "fragments" so that the update process can >distinguish them. In which case it is semantically identical to the current >scheme. > >Or are you proposing changing the update process so that it looks at the >new TLV? I guess that must be what you have in mind. This has fairly >serious consequences if you have migrated to extended numbers, but you then >introduce a router which doesn't understand the new update process. I >thought we had already considered and rejected solutions of this type. > > Mike > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > >Hi Amir/Stefano/Mike, > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > >what you thought of it. > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > >number in the psudonode-id is not used. The changes required are minimum. >We > >anyway scan thru TLV's for authentication information, we can find the LSP > >number TLV then. We instead use this TLV. > > > >To migrate to such a method all we need to do is to, use same LSP numbers >in > >the header and the TLV, and once all routers recognize the TLV, we actually > >can use different numbers. This does not create any backward compatibility > >issues and so we dont need two methods. In this case we do not need to >worry > >about Attached bit, Partition repair bit or change to SPF calculations etc. > >The solution also seems a logical extension, to the constraint caused by 8 > >bit LSP number value. Rather than a solution that has multiple system id's > >which is like fooling the IS to believe all the systems are the same. > > > >Thanks, > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 10:42:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14981 for ; Wed, 24 Apr 2002 10:42:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OEPst19598; Wed, 24 Apr 2002 07:25:54 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OELHt19570 for ; Wed, 24 Apr 2002 07:21:17 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , "'Radia Perlman - Boston Center for Networking'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 10:24:26 -0400 > > 1) I'd assume that SNPs should use the link secret, since they are > > not forwarded > > > > Radia > > SNPs use area/domain passwords as specified in ISO 10589 7.3.15.3a. > (and other places) > > Les Les - That is the standard, but Radia has an interesting point. Doesn't the use of an area secret allow some replay attacks? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 11:30:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18886 for ; Wed, 24 Apr 2002 11:30:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OFE2t19873; Wed, 24 Apr 2002 08:14:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OFDet19861 for ; Wed, 24 Apr 2002 08:13:40 -0700 (PDT) (envelope-from rja@extremenetworks.com) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 562B667103; Wed, 24 Apr 2002 11:54:37 -0400 (EDT) Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "IS-IS-WG (E-mail)" To: Jeff Parker From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 11:26:44 -0400 Content-Transfer-Encoding: 7bit On Wednesday, April 24, 2002, at 10:24 , Jeff Parker wrote: > > That is the standard, but Radia has an interesting point. > Doesn't the use of an area secret allow some replay attacks? The objective is to document what ISPs have already widely deployed, not invent something new. The other thing to keep in mind is that the ISPs merely want to have protection from eavesdropping on cleartext IS-IS passwords. The deployed approach totally solves that problem. Note also that when I proposed something different than what is deployed, there was overwhelming push-back from operators saying the above. This thing was *deployed* several years ago. We just need to document what has been deployed in an Informational RFC. If folks want to do something different, then that should be a separate activity in a separate document and should NOT delay publication of the deployed mechanism. Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 11:44:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19762 for ; Wed, 24 Apr 2002 11:44:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OFS2t19959; Wed, 24 Apr 2002 08:28:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OFRRt19947 for ; Wed, 24 Apr 2002 08:27:27 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'RJ Atkinson'" , Jeff Parker Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 11:40:41 -0400 Ran - I appreciate the force of your argument to document rather than invent, and I may borrow some of your prose in the future. I'm not suggesting we delay the document. But I would think this is an appropriate place to discuss potential vulnerabilities in the protocol. We have a few authentication types left, and someone could draft a newer protocol if there is a need. But perhaps this line of questioning is misguided. Is this a threat you have evaluated, and decided we don't need to worry about this? - jeff parker > On Wednesday, April 24, 2002, at 10:24 , Jeff Parker wrote: > > > > That is the standard, but Radia has an interesting point. > > Doesn't the use of an area secret allow some replay attacks? > > The objective is to document what ISPs have already widely deployed, > not invent something new. The other thing to keep in mind is that > the ISPs merely want to have protection from eavesdropping on > cleartext > IS-IS passwords. The deployed approach totally solves that problem. > > Note also that when I proposed something different than what > is deployed, > there was overwhelming push-back from operators saying the above. > > This thing was *deployed* several years ago. We just need to document > what has been deployed in an Informational RFC. > > If folks want to do something different, then that should be > a separate activity in a separate document and should NOT > delay publication of the deployed mechanism. > > Ran > rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 14:40:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18157 for ; Wed, 24 Apr 2002 14:40:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OIP1t20873; Wed, 24 Apr 2002 11:25:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OIO8t20857 for ; Wed, 24 Apr 2002 11:24:09 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR200F>; Wed, 24 Apr 2002 14:37:26 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 14:37:05 -0400 Hi Mike, Thanks a lot for the reply. That helped clarify a lot. I was actually thinking things from the LSP aspect and forgot all about the xSNP thing altogather. ;-) > Where do you put the extended numbers in xSNPs? Or are you proposing a new > "extended" LSP entry TLV? What do you do for migration? send both? I guess we need to send both, so it would actually be more than one(two) new TLV's added because of the draft, agreed. > Even if you do this, if you have a router which doesn't understand the new > stuff and you are using the extended number space, you will get perpetual > re-transmission if you have two LSPs with the same "natural" number but > different extended numbers sent to a non-participating router. It will only > ACK one of them. et.c etc. Though I do not understand what you mean by "with the same "natural" number but different extended numbers sent to a non-participating router" Well the ack with either of the TLV's can be treated as the ack for the element. Or are you talking about a case after migrating we get a guy who doesn't understand the new TLV? If thats the case I have already given the instance of domain wide and wide metrics.;-) Do you think the method is not worth it?(My view is that this seems the logical extension and if the number of changes this way are lesser we could as well go in for it) (any other changes you think would be required?);-) Thanks, Vishwas >-----Original Message----- >From: Manral, Vishwas [mailto:VishwasM@netplane.com] >Sent: Tuesday, April 23, 2002 8:51 PM >To: 'mike shand' >Cc: 'isis-wg@spider.juniper.net' >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >Hi Mike, > >Thanks for the reply. > >I do not understand if we have migrated to a bigger LSp number, why we would >bring in a router that still uses a smaller LSP number, even when we know it >could create problems. This problem can occur in all cases of migration >a) to domain wide >b) wide metrics > >I do not see why we should introduce a two pronged method to do something >which we can do pretty easily with just a TLV change, when similar >approaches have been taken for other cases. Even in domain wide if a router >came in which did not use external reachability in cases of L1 area the same >problem would occur. I do not find the reason convincing enough to be >rejected. ;-) > >Thanks, >Vishwas > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Tuesday, April 23, 2002 6:13 PM >To: Manral, Vishwas >Cc: 'isis-wg@spider.juniper.net' >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >I'm not sure I fully understand this proposal. I assume that when you >actually start using extended numbers you still need to invent additional >system ID's for the extra "fragments" so that the update process can >distinguish them. In which case it is semantically identical to the current >scheme. > >Or are you proposing changing the update process so that it looks at the >new TLV? I guess that must be what you have in mind. This has fairly >serious consequences if you have migrated to extended numbers, but you then >introduce a router which doesn't understand the new update process. I >thought we had already considered and rejected solutions of this type. > > Mike > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > >Hi Amir/Stefano/Mike, > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > >what you thought of it. > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > >number in the psudonode-id is not used. The changes required are minimum. >We > >anyway scan thru TLV's for authentication information, we can find the LSP > >number TLV then. We instead use this TLV. > > > >To migrate to such a method all we need to do is to, use same LSP numbers >in > >the header and the TLV, and once all routers recognize the TLV, we actually > >can use different numbers. This does not create any backward compatibility > >issues and so we dont need two methods. In this case we do not need to >worry > >about Attached bit, Partition repair bit or change to SPF calculations etc. > >The solution also seems a logical extension, to the constraint caused by 8 > >bit LSP number value. Rather than a solution that has multiple system id's > >which is like fooling the IS to believe all the systems are the same. > > > >Thanks, > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 14:43:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18266 for ; Wed, 24 Apr 2002 14:43:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OIT1t20906; Wed, 24 Apr 2002 11:29:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OISPt20894 for ; Wed, 24 Apr 2002 11:28:25 -0700 (PDT) (envelope-from rja@extremenetworks.com) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 6896067105; Wed, 24 Apr 2002 15:09:37 -0400 (EDT) Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "IS-IS-WG (E-mail)" To: Jeff Parker From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 14:41:43 -0400 Content-Transfer-Encoding: 7bit On Wednesday, April 24, 2002, at 11:40 , Jeff Parker wrote: > Ran - > I appreciate the force of your argument to document > rather than invent, and I may borrow some of your prose > in the future. I'm not suggesting we delay the document. Thanks. > But I would think this is an appropriate place to > discuss potential vulnerabilities in the protocol. We > have a few authentication types left, and someone could > draft a newer protocol if there is a need. Certainly someone could define a different approach in a separate document if there were interest. My main concern is that we not gate publishing the current draft on some new project. And it is well known that I believe that documents discussing potential vulnerabilities of protocol X are always in-scope for a working group focused on protocol X. So if some folks wanted to write up a separate informational document with a security analysis of I/IS-IS, that would be all goodness in my book. > But perhaps this line of questioning is misguided. > Is this a threat you have evaluated, and decided we > don't need to worry about this? I'll answer this question, but maybe in a different way than some expect. I've thought a lot about routing protocol security. And I think the next useful increment of security (beyond the simple cryptographic authentication in the current draft) is probably to go to a public-key approach. At a high-level, routing protocols already need to be able to handle duplicate packets (i.e. replays) because packet/frame duplication happens by accident (no malice) in the global Internet anyway. So a robust IS-IS implementation probably won't be very badly affected by packet replay. For non-robust implementations, any number of things could be a problem -- but that is an implementation quality issue IMHO. For OSPF, RFC-2154 outlines the use of public-key digital signatures to improve the protection beyond OSPF MD5. So my suggestion is that if folks want to go beyond the current IS-IS cryptographic authentication, those folks should look into a digital signature approach comparable to RFC-2154. Now my conversations with users/operators makes me believe that operators are very unlikely to deploy anything other than the currently deployed MD5 spec. But a digital signature approach to IS-IS would certainly make interesting research. Cheers, Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 17:38:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10010 for ; Wed, 24 Apr 2002 17:38:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OLI1t21729; Wed, 24 Apr 2002 14:18:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OLHgt21717 for ; Wed, 24 Apr 2002 14:17:42 -0700 (PDT) (envelope-from Radia.Perlman@sun.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3OLV5667593 for ; Wed, 24 Apr 2002 14:31:05 -0700 (PDT) X-JNPR-Received-From: outside Received: from patan.sun.com ([192.18.98.43]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 24 Apr 2002 14:29:06 -0700 Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10931; Wed, 24 Apr 2002 15:31:01 -0600 (MDT) Received: from sr1-ubur-02 (sr1-ubur-02 [129.148.9.81]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id RAA12111; Wed, 24 Apr 2002 17:31:01 -0400 (EDT) Message-Id: <200204242131.RAA12111@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt To: Radia.Perlman@sun.com, tli@procket.com Cc: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8qES6CskDldMfiEMafIVGw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc X-OriginalArrivalTime: 24 Apr 2002 21:29:07.0046 (UTC) FILETIME=[1080D860:01C1EBD7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 17:31:00 -0400 (EDT) Answering Tony Li's comments on my comments (my original comments have a line in front, and are most indented, Tony's comments are indented and unlined): | 1) I'd assume that SNPs should use the link secret, since they are | not forwarded Yes, but they can be replicated on multiple links. This simplifies implementation. I guess the CSNP would be identical on each link, but a PSNP would not. But I guess that's a plausible reason for making it the area secret. | 2) I remember IS-IS having a set of acceptable receive secrets, | and a single transmit password, so that secret rollover wouldn't | be a problem. This draft seems to imply there's only a single one. That is certainly an implementation option. Wouldn't it affect the management, i.e., that setting the receive secret would involve a set of things rather than a single thing? I think it's important to do this (allow multiple receive secrets) so it is easy to migrate from one secret to another. I remember designing that for IS-IS a long time ago, and being very explicit about the multiple receive secrets. Is there still text around in some document recommending this, or does all the text these days mention a single secret? Does the MIB allow setting multiple receive secrets? | 3) Shouldn't there be a separate layer 1 and layer 2 link secret? | (Again, I think I remember that from DECnet). What is gained from this? So that layer 1 routers can't generate layer 2 messages (and vice versa). [Side question: what is gained from multiple secrets anyhow?] Do you mean layer 1 plus layer 2 secrets? That's to keep each logical trust group separate. Or do you mean multiple receive secrets? That's for easy secret rollover. To get from secret a to secret b, one by one have routers add secret b to their allowable receive secrets. Then once everyone accepts both, one by one change their transmit secret to b. Once everyone has their transmit secret as b, then one by one remove a from the acceptable receive set. I know of no installations where someone would allow an L1 adjacency but not an L2. Seems like it could be simplified... Well again, working from ancient memory...it was designed so that L2 routers could form adjacencies over the same wire as L1 routers, and even allowed mutliple L1 areas on the same LAN. It's good cryptographic practice to have each separate community of trust have a different secret. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 18:08:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10299 for ; Wed, 24 Apr 2002 18:08:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OLqht21933; Wed, 24 Apr 2002 14:52:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OLl2t21904 for ; Wed, 24 Apr 2002 14:47:02 -0700 (PDT) (envelope-from jparker@axiowave.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3OM0Q668396 for ; Wed, 24 Apr 2002 15:00:26 -0700 (PDT) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 24 Apr 2002 14:58:27 -0700 Message-ID: From: Jeff Parker To: "'Radia Perlman - Boston Center for Networking'" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Apr 2002 21:58:27.0718 (UTC) FILETIME=[29F21260:01C1EBDB] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 18:00:20 -0400 > Does the MIB allow setting multiple receive secrets? > > Radia In the past the MIB discussed authentication, but I was asked to remove it to improve security. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 19:03:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11167 for ; Wed, 24 Apr 2002 19:03:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OMlht22242; Wed, 24 Apr 2002 15:47:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OMi5t22214 for ; Wed, 24 Apr 2002 15:44:05 -0700 (PDT) (envelope-from zinin@psg.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3OMvU669644 for ; Wed, 24 Apr 2002 15:57:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from psg.com ([147.28.0.62]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 24 Apr 2002 15:34:23 -0700 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 170VN7-00024j-00; Wed, 24 Apr 2002 15:36:21 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6629208368.20020424153556@psg.com> To: Radia Perlman - Boston Center for Networking CC: tli@procket.com, isis-wg@juniper.net Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt In-Reply-To: <200204242131.RAA12111@bcn.East.Sun.COM> References: <200204242131.RAA12111@bcn.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2002 22:34:23.0593 (UTC) FILETIME=[2EF27D90:01C1EBE0] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 15:35:56 -0700 Content-Transfer-Encoding: 7bit Radia, Just one comment: > | 2) I remember IS-IS having a set of acceptable receive secrets, > | and a single transmit password, so that secret rollover wouldn't > | be a problem. This draft seems to imply there's only a single one. > That is certainly an implementation option. > Wouldn't it affect the management, i.e., that setting the receive secret > would involve a set of things rather than a single thing? I think it's > important to do this (allow multiple receive secrets) > so it is easy to migrate from one secret to another. I remember designing > that for IS-IS a long time ago, and being very explicit about the multiple > receive secrets. Is there still text around in some document recommending > this, or does all the text these days mention a single secret? Does > the MIB allow setting multiple receive secrets? The draft actually talks about this: An implementation MAY check a set of passwords when verifying the Authentication Value. This provides a mechanism for incrementally changing passwords in a network. I don't know about the MIB part. Cheers! Alex _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 19:33:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11665 for ; Wed, 24 Apr 2002 19:33:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3OND1t22387; Wed, 24 Apr 2002 16:13:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3ONCZt22375 for ; Wed, 24 Apr 2002 16:12:35 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3ONQ0n86921 for ; Wed, 24 Apr 2002 16:26:00 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 24 Apr 2002 16:09:55 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA17373 for ; Wed, 24 Apr 2002 16:11:54 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G8NK1G>; Wed, 24 Apr 2002 16:11:54 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F986@avalon.pluris.com> From: Les Ginsberg To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Apr 2002 23:09:55.0718 (UTC) FILETIME=[25CAF260:01C1EBE5] Subject: [Isis-wg] Comments on draft-ietf-isis-hmac-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 16:11:52 -0700 Section 2.1 of "draft-ietf-isis-hmac-03.txt" discusses a problem associated with password rollover immediately preceeding a router restart. If the restarted router has not yet regenerated and propagated its own LSPs based on the new password configuration then the restarted router is not able to accept its own stale LSPs as propagated by its neighbors and would therefore not increase the sequence # of its locally generated LSPs to allow other routers to recognize these copies as "newer". The draft suggests that an implementation cautiously accept the LSPs which fail authentication if these LSPs have the local system ID in the first portion of the LSPID field AND have a higher sequence number than the local copy. The authors admit this leaves the system open to replay attacks. Text below discusses alternative solutions to the problem which present no backwards compatibility problems and eliminate the need for bypassing authentication. We propose that the solutions be incorporated into a revised version of the draft. Les Ginsberg/Satish Dattatri -------------------------------------------------- The likelihood of this problem occurring is significantly reduced by proper implementation of a Defect Report against ISO 10589 filed in April 1993. At that time it was noted that: "While ISO 10589 adequately covers all the conditions for processing received LSPs and determining whether a received LSP is newer than an LSP already stored by an IS, the same level of description is not available for the processing of SNPs. The intention is that the same procedures apply to SNPs as to LSPs, but this is not explicitly stated in the applicable clause(7.3.15.2)." The remedy for this omission is to apply the description of LSP confusion(7.3.16.2) and Remaining Lifetime(7.3.16.3) to the processing of SNPs. The textual changes have been incorporated into ISO 10589:2001 (see 7.3.16.2, 7.3.16.3, and 7.3.15.2b). Most relevant to the issue raised in Section 2.1 of the draft is to note that if an IS receives an SNP entry which specifies an LSP generated by the local system which is newer than the local copy, it must regenerate its local copy with a sequence number one greater than that in the corresponding SNP entry. Since the SNP contains current authentication it is accepted and all SNP entries it contains are processed. This means that in most scenarios the problem described in the draft is resolved by the normal exchange of CSNPs following Pt-Pt adjacency establishment and the processing of periodic CSNPs from the DIS on a LAN. A few "corner cases" remain: Case 1: If the restarted router becomes the DIS on a LAN, it will generate, not receive, periodic CSNPs. Systems which have a stale LSP generated by a previous incarnation of the restarted system will respond to the corresponding SNP entry by sending that stale LSP onto the LAN. Case 2: If the link layer on a Pt-Pt circuit does not provide reliable delivery, then it is possible for one or more of the initial CSNPs to be lost. In this case the restarted router may never receive an SNP entry for one or more stale LSPs. Case 3: On a Pt-Pt circuit a stale LSP may arrive at a neighbor from some other IS (not a neighbor of the restarted router) shortly after the exchange of initial CSNPs. This LSP will never be seen by the restarted router as an entry in a CSNP. (Note: Periodic CSNPs will overcome cases 2 and 3, but periodic CSNPs are not required on a Pt-Pt circuit.) In all of these cases, the stale LSPs will be sent by neighbors of the restarted router but will be ignored by the restarted router due to authentication failure. Two solutions are available to resolve these cases without the need to bypass authentication checks. Solution #1: The rules for processing a received LSP generated by some other system which is "older" than the local copy, as described in 7.3.15.1e)3) of ISO 10589:1992 must be amended as follows: "If the (received)LSP is older than the one in the database and the copy in the database contains Authentication Information then a recheck of the authentication information shall be performed. If this check fails, the Remaining Lifetime in the local copy shall be set to 0 and the actions described in 7.3.16.4 shall be taken. Otherwise Set SRMflag for C and Clear SSNflag for C" Similarly, the rules for processing a received SNP entry which describe an LSP older than the one in the local database, as described in 7.3.15.2b)2) of ISO 10589:1992 must be amended as follows: "If the reported value is older than the database value and the LSP source is some other system and the copy in the database contains Authentication Information then a recheck of the authentication information shall be performed. If this check fails, the Remaining Lifetime in the local copy shall be set to 0 and the actions described in 7.3.16.4 shall be taken. Otherwise Set SRMflag for C and Clear SSNflag for C" Solution #2: When a router restarts and authentication is enabled locally at the corresponding level, the router assigns itself a temporary LAN priority of 0, making it the least likely system to be elected DIS. This temporary priority shall be maintained until a complete set of CSNPs has been received and no SRMflags have been set on that circuit for any local LSPs which were reported in that set of CSNPs. (NOTE: If all systems on the LAN are set to priority 0 then it is still possible for the restarted router to be elected DIS - so this solution is not bullet-proof.) Discussion: Solution #1 requires routers to recheck authentication on the LSP copy in their database in the event they receive an LSP/SNP entry for an LSP generated by another system and is OLDER than the one in the local database. If the authentication recheck fails the LSP is purged. Since the system is required to insert current authentication information when purging an LSP, this resolves the problem without requiring the system to be vulnerable to replay attacks. (It is important to note that when purging an LSP a router must always include authentication information based on the current local password configuration.) Solution #1 addresses all problem cases noted above. But until all routers implement solution #1, there is some possibility that some of the problem cases identified above may not be resolved. Of the three mentioned, Case #1 is the most likely to happen. Solution # 2 is offered to handle that case. Cases #2 and #3 are very unlikely to occur. If they do occur, then LSP DB synchronization will be incomplete until all stale LSPs age out. The possibility of this occurring exists in current networks i.e. this problem has not been introduced by the HMAC extension - it can occur using plain text passwords as well. Accepting the low probability of the occurence of Problems #2 and #3 (until all routers can be upgraded to support Solution #1) may be preferable to bypassing authentication. However, network administrators may still prefer to have a knob which bypasses password authentication for locally generated LSPs so as to be able to overcome the rare instance when the extensions to the protocol are insufficient. The period of time this knob is enabled should be minimized so as to minimize risk to the network. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 24 20:38:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12398 for ; Wed, 24 Apr 2002 20:38:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P0N1t22794; Wed, 24 Apr 2002 17:23:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P0M4t22769 for ; Wed, 24 Apr 2002 17:22:04 -0700 (PDT) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3P0ZS672049 for ; Wed, 24 Apr 2002 17:35:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 24 Apr 2002 17:17:39 -0700 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id 3C31B3442D; Wed, 24 Apr 2002 17:24:15 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g3P0JcvM025817; Wed, 24 Apr 2002 17:19:38 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g3P0Jb5v021527; Wed, 24 Apr 2002 17:19:37 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15559.19353.830992.907168@alpha-tli.procket.com> To: Radia Perlman - Boston Center for Networking Cc: tli@procket.com, isis-wg@juniper.net Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt In-Reply-To: <200204242131.RAA12111@bcn.East.Sun.COM> References: <200204242131.RAA12111@bcn.East.Sun.COM> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 25 Apr 2002 00:17:39.0968 (UTC) FILETIME=[9C464800:01C1EBEE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Apr 2002 17:19:37 -0700 Content-Transfer-Encoding: 7bit Radia | Well again, working from ancient memory...it was designed so that | L2 routers could form adjacencies over the same wire as L1 routers, | and even allowed mutliple L1 areas on the same LAN. It's good | cryptographic practice to have each separate community of trust have | a different secret. My point is that in modern deployment, the trust area is the entire routing domain. And not one more micron. ;-) Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 02:50:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27905 for ; Thu, 25 Apr 2002 02:50:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P6Y1t24631; Wed, 24 Apr 2002 23:34:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P6Xmt24619 for ; Wed, 24 Apr 2002 23:33:49 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJA5T>; Thu, 25 Apr 2002 02:47:09 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 02:46:53 -0400 Hi Mike, I actually thought over it, and simplified things a bit further, so that we never have to send both entry TLV's at one time. 1. All routers use small LSP numbers at init time. 2. As routers with new functionality come up, they need to send the same value in header and TLV LSP numbers. They need to be ready to accept the "extended LSP entry TLV. We however still send the old LSP entry TLV. 3. Once all routers have the capability, we start using different values in LSP number in the header and the TLV(extended LSP number) and use only extended LSP entry TLV. Does this sound ok? ;-) Thanks, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, April 24, 2002 7:55 PM To: Manral, Vishwas Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: >Hi folks, > >As I have not got the reply to my mail, I will try and restate(I guess I >wasn't clear) what the proposal is. > >The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit >LSP number. The new TLV is propagated in all LSP's and overrides the LSP >Number field in the header. > >To migrate to this scheme, as long as all the routers in the network do not >support the new TLV, we use the same value in LSP number field in the header >as well as the TLV. Once all the routers in the network support the new TLV, >we can actually use the value of the LSP number TLV and ignore the LSP >number field in the header. > >The solution in this scheme seems to be a logical extension to the limit >caused by an 8 bit LSP number field, using a 32 bit sequence number, rather >than the scheme where we need multiple system id's and then equating the >ID's. > >The advantages of the scheme relative to the other scheme is: - > >a) We use a simple migration scheme rather than a two step highly complex >scheme. >b) We need not worry about any change to routing table calculations. >c) No taking care of attached bit. >d) No taking care of partition bit. >e) We need not worry about which links use what system id(as in the other >scheme) and hence a lot of configuration. >f) The amount of code changes are minimal. > >Regarding Mike's comment(I hope I got it right, Mike?) what happens when a >new router that does not support the functionality comes up. Although the >assumption with the other drafts like domain-wide and wide metrics is that >once we migrate to a scheme, we will not try and bother about the older >scheme, the same problem would occur in the other draft too if a new router >came up after we had migrated to method 2, and someone did not understand >the ISIS Alias TLV described there. Routing loops could very easily occur >there. Where do you put the extended numbers in xSNPs? Or are you proposing a new "extended" LSP entry TLV? What do you do for migration? send both? Even if you do this, if you have a router which doesn't understand the new stuff and you are using the extended number space, you will get perpetual re-transmission if you have two LSPs with the same "natural" number but different extended numbers sent to a non-participating router. It will only ACK one of them. et.c etc. Mike >Any comments/criticism invited. > >Thanks a lot, >Vishwas > >-----Original Message----- >From: Manral, Vishwas [mailto:VishwasM@netplane.com] >Sent: Tuesday, April 23, 2002 8:51 PM >To: 'mike shand' >Cc: 'isis-wg@spider.juniper.net' >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >Hi Mike, > >Thanks for the reply. > >I do not understand if we have migrated to a bigger LSp number, why we would >bring in a router that still uses a smaller LSP number, even when we know it >could create problems. This problem can occur in all cases of migration >a) to domain wide >b) wide metrics > >I do not see why we should introduce a two pronged method to do something >which we can do pretty easily with just a TLV change, when similar >approaches have been taken for other cases. Even in domain wide if a router >came in which did not use external reachability in cases of L1 area the same >problem would occur. I do not find the reason convincing enough to be >rejected. ;-) > >Thanks, >Vishwas > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Tuesday, April 23, 2002 6:13 PM >To: Manral, Vishwas >Cc: 'isis-wg@spider.juniper.net' >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >I'm not sure I fully understand this proposal. I assume that when you >actually start using extended numbers you still need to invent additional >system ID's for the extra "fragments" so that the update process can >distinguish them. In which case it is semantically identical to the current >scheme. > >Or are you proposing changing the update process so that it looks at the >new TLV? I guess that must be what you have in mind. This has fairly >serious consequences if you have migrated to extended numbers, but you then >introduce a router which doesn't understand the new update process. I >thought we had already considered and rejected solutions of this type. > > Mike > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > >Hi Amir/Stefano/Mike, > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > >what you thought of it. > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > >number in the psudonode-id is not used. The changes required are minimum. >We > >anyway scan thru TLV's for authentication information, we can find the LSP > >number TLV then. We instead use this TLV. > > > >To migrate to such a method all we need to do is to, use same LSP numbers >in > >the header and the TLV, and once all routers recognize the TLV, we actually > >can use different numbers. This does not create any backward compatibility > >issues and so we dont need two methods. In this case we do not need to >worry > >about Attached bit, Partition repair bit or change to SPF calculations etc. > >The solution also seems a logical extension, to the constraint caused by 8 > >bit LSP number value. Rather than a solution that has multiple system id's > >which is like fooling the IS to believe all the systems are the same. > > > >Thanks, > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 03:11:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28076 for ; Thu, 25 Apr 2002 03:11:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P6uit24767; Wed, 24 Apr 2002 23:56:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P6nmt24718 for ; Wed, 24 Apr 2002 23:49:48 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4169.cisco.com [10.50.16.72]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10233; Thu, 25 Apr 2002 08:02:41 +0100 (BST) Message-Id: <4.3.2.7.2.20020425075004.04165290@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: mike shand Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 08:01:51 +0100 At 14:37 24/04/2002 -0400, Manral, Vishwas wrote: >Hi Mike, > >Thanks a lot for the reply. That helped clarify a lot. I was actually >thinking things from the LSP aspect and forgot all about the xSNP thing >altogather. ;-) > > > Where do you put the extended numbers in xSNPs? Or are you proposing a new > > > "extended" LSP entry TLV? What do you do for migration? send both? >I guess we need to send both, so it would actually be more than one(two) new >TLV's added because of the draft, agreed. So this means we more than double the size of any xSNPs we send during the migration period (which probably needs to last a long time so that we can be SURE there will never be an old router anywhere). Even so I am very nervous about the catastrophe which would result if an old router subsequently crept in. > > Even if you do this, if you have a router which doesn't understand the new > > > stuff and you are using the extended number space, you will get perpetual > > re-transmission if you have two LSPs with the same "natural" number but > > different extended numbers sent to a non-participating router. It will >only > > ACK one of them. et.c etc. >Though I do not understand what you mean by > >"with the same "natural" number but different extended numbers sent to a >non-participating router" I mean that a router that doesn't understand the new TLVs receives two LSPs with the same LSP number in the header, but different LSP numbers in the new TLV. It will treat them as duplicates of the same LSP and so when it acknowledges the second one it will just send a normal PSNP and the originator will not be able to tell which one was being acknowledged. I haven't thought it through in detail, but it seems to me that for various scenarios you will get the possibility of perpetual retransmissions, and certainly loss of information. >Well the ack with either of the TLV's can be treated as the ack for the >element. Or are you talking about a case after migrating we get a guy who >doesn't understand the new TLV? If thats the case I have already given the >instance of domain wide and wide metrics.;-) > >Do you think the method is not worth it?(My view is that this seems the >logical extension and if the number of changes this way are lesser we could >as well go in for it) (any other changes you think would be required?);-) My view is that the update process is extremely subtle (but has been proved correct in its current form) and that changing it in any way is very risky. I would MUCH rather have a solution which left the update process unchanged. >Thanks, >Vishwas > > > >-----Original Message----- > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > >Sent: Tuesday, April 23, 2002 8:51 PM > >To: 'mike shand' > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >Hi Mike, > > > >Thanks for the reply. > > > >I do not understand if we have migrated to a bigger LSp number, why we >would > >bring in a router that still uses a smaller LSP number, even when we know >it > >could create problems. This problem can occur in all cases of migration > >a) to domain wide > >b) wide metrics > > > >I do not see why we should introduce a two pronged method to do something > >which we can do pretty easily with just a TLV change, when similar > >approaches have been taken for other cases. Even in domain wide if a router > >came in which did not use external reachability in cases of L1 area the >same > >problem would occur. I do not find the reason convincing enough to be > >rejected. ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Tuesday, April 23, 2002 6:13 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >I'm not sure I fully understand this proposal. I assume that when you > >actually start using extended numbers you still need to invent additional > >system ID's for the extra "fragments" so that the update process can > >distinguish them. In which case it is semantically identical to the current > >scheme. > > > >Or are you proposing changing the update process so that it looks at the > >new TLV? I guess that must be what you have in mind. This has fairly > >serious consequences if you have migrated to extended numbers, but you then > >introduce a router which doesn't understand the new update process. I > >thought we had already considered and rejected solutions of this type. > > > > Mike > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > >Hi Amir/Stefano/Mike, > > > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > > >what you thought of it. > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > > >number in the psudonode-id is not used. The changes required are minimum. > >We > > >anyway scan thru TLV's for authentication information, we can find the >LSP > > >number TLV then. We instead use this TLV. > > > > > >To migrate to such a method all we need to do is to, use same LSP numbers > >in > > >the header and the TLV, and once all routers recognize the TLV, we >actually > > >can use different numbers. This does not create any backward >compatibility > > >issues and so we dont need two methods. In this case we do not need to > >worry > > >about Attached bit, Partition repair bit or change to SPF calculations >etc. > > >The solution also seems a logical extension, to the constraint caused by >8 > > >bit LSP number value. Rather than a solution that has multiple system >id's > > >which is like fooling the IS to believe all the systems are the same. > > > > > >Thanks, > > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 03:37:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28358 for ; Thu, 25 Apr 2002 03:36:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P7L8t24932; Thu, 25 Apr 2002 00:21:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P7CTt24877 for ; Thu, 25 Apr 2002 00:12:29 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJA6S>; Thu, 25 Apr 2002 03:25:50 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 03:25:45 -0400 Mike, Thanks a lot for the reply. My comments inline, prefixed by a VM>. Thanks, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Thursday, April 25, 2002 12:32 PM To: Manral, Vishwas Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt At 14:37 24/04/2002 -0400, Manral, Vishwas wrote: >Hi Mike, > >Thanks a lot for the reply. That helped clarify a lot. I was actually >thinking things from the LSP aspect and forgot all about the xSNP thing >altogather. ;-) > > > Where do you put the extended numbers in xSNPs? Or are you proposing a new > > > "extended" LSP entry TLV? What do you do for migration? send both? >I guess we need to send both, so it would actually be more than one(two) new >TLV's added because of the draft, agreed. So this means we more than double the size of any xSNPs we send during the migration period (which probably needs to last a long time so that we can be SURE there will never be an old router anywhere). Even so I am very nervous about the catastrophe which would result if an old router subsequently crept in. VM> I guess we could do with just one TLV at a time, as in my previous mail. Talking about problems. I guess there would be routing table problems in case a new router came in after we migrated to method 2. > > Even if you do this, if you have a router which doesn't understand the new > > > stuff and you are using the extended number space, you will get perpetual > > re-transmission if you have two LSPs with the same "natural" number but > > different extended numbers sent to a non-participating router. It will >only > > ACK one of them. et.c etc. >Though I do not understand what you mean by > >"with the same "natural" number but different extended numbers sent to a >non-participating router" I mean that a router that doesn't understand the new TLVs receives two LSPs with the same LSP number in the header, but different LSP numbers in the new TLV. It will treat them as duplicates of the same LSP and so when it acknowledges the second one it will just send a normal PSNP and the originator will not be able to tell which one was being acknowledged. I haven't thought it through in detail, but it seems to me that for various scenarios you will get the possibility of perpetual retransmissions, and certainly loss of information. VM> Same answer as above. A similar thing could happen of the ext_lsp_frag too if a router came without which did not understand the new TLV, it would cause routing loops too. >Well the ack with either of the TLV's can be treated as the ack for the >element. Or are you talking about a case after migrating we get a guy who >doesn't understand the new TLV? If thats the case I have already given the >instance of domain wide and wide metrics.;-) > >Do you think the method is not worth it?(My view is that this seems the >logical extension and if the number of changes this way are lesser we could >as well go in for it) (any other changes you think would be required?);-) My view is that the update process is extremely subtle (but has been proved correct in its current form) and that changing it in any way is very risky. I would MUCH rather have a solution which left the update process unchanged. VM> Mike, I think the only change to the update process would be to use new TLV's. The Update process as such would not change much but treating both the TLV's as the same. The point here is that we need to do the check only at the time of migrating and not after we have migrated, and there is no change once we have migrated. I agree a big change to the Update process causes more problems than a change to the SPF and a lot of extra configuration. >Thanks, >Vishwas > > > >-----Original Message----- > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > >Sent: Tuesday, April 23, 2002 8:51 PM > >To: 'mike shand' > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >Hi Mike, > > > >Thanks for the reply. > > > >I do not understand if we have migrated to a bigger LSp number, why we >would > >bring in a router that still uses a smaller LSP number, even when we know >it > >could create problems. This problem can occur in all cases of migration > >a) to domain wide > >b) wide metrics > > > >I do not see why we should introduce a two pronged method to do something > >which we can do pretty easily with just a TLV change, when similar > >approaches have been taken for other cases. Even in domain wide if a router > >came in which did not use external reachability in cases of L1 area the >same > >problem would occur. I do not find the reason convincing enough to be > >rejected. ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Tuesday, April 23, 2002 6:13 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >I'm not sure I fully understand this proposal. I assume that when you > >actually start using extended numbers you still need to invent additional > >system ID's for the extra "fragments" so that the update process can > >distinguish them. In which case it is semantically identical to the current > >scheme. > > > >Or are you proposing changing the update process so that it looks at the > >new TLV? I guess that must be what you have in mind. This has fairly > >serious consequences if you have migrated to extended numbers, but you then > >introduce a router which doesn't understand the new update process. I > >thought we had already considered and rejected solutions of this type. > > > > Mike > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > >Hi Amir/Stefano/Mike, > > > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > > >what you thought of it. > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > > >number in the psudonode-id is not used. The changes required are minimum. > >We > > >anyway scan thru TLV's for authentication information, we can find the >LSP > > >number TLV then. We instead use this TLV. > > > > > >To migrate to such a method all we need to do is to, use same LSP numbers > >in > > >the header and the TLV, and once all routers recognize the TLV, we >actually > > >can use different numbers. This does not create any backward >compatibility > > >issues and so we dont need two methods. In this case we do not need to > >worry > > >about Attached bit, Partition repair bit or change to SPF calculations >etc. > > >The solution also seems a logical extension, to the constraint caused by >8 > > >bit LSP number value. Rather than a solution that has multiple system >id's > > >which is like fooling the IS to believe all the systems are the same. > > > > > >Thanks, > > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 03:40:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28419 for ; Thu, 25 Apr 2002 03:40:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P7OZt24957; Thu, 25 Apr 2002 00:24:35 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P74Wt24822 for ; Thu, 25 Apr 2002 00:04:32 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4169.cisco.com [10.50.16.72]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10453; Thu, 25 Apr 2002 08:17:25 +0100 (BST) Message-Id: <4.3.2.7.2.20020425080623.04406378@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: mike shand Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 08:16:34 +0100 At 02:46 25/04/2002 -0400, Manral, Vishwas wrote: >Hi Mike, > >I actually thought over it, and simplified things a bit further, so that we >never have to send both entry TLV's at one time. > >1. All routers use small LSP numbers at init time. >2. As routers with new functionality come up, they need to send the same >value in header and TLV LSP numbers. They need to be ready to accept the >"extended LSP entry TLV. We however still send the old LSP entry TLV. >3. Once all routers have the capability, we start using different values in >LSP number in the header and the TLV(extended LSP number) and use only >extended LSP entry TLV. I think you need a multi stage migration process. 1. Deploy new software everywhere which understands the new TLVs, and sends the same LSP number in both the LSP header and the extended TLV, but still only sends the old LSP entry TLV. 2. Once you have all routers with the new software, you can go to each router in turn and tell it to use new LSP entries instead of old. 3. Once you have all routers doing this, you can start using extended LSP numbers (i.e. different values in the TLV and the header). It would probably be wise to include some capability bits in the IIHs to prevent forming adjacencies with old routers once you have started using extended LSP numbers. But, note that this is a complex process and requires changes to all the update process code AND the SPF process code to recognize the additional LSP numbers, AND the hello processing code (if we want to make it reasonably safe). I'd MUCH rather confine the changes to the SPF. Mike >Does this sound ok? ;-) > >Thanks, >Vishwas > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Wednesday, April 24, 2002 7:55 PM >To: Manral, Vishwas >Cc: 'isis-wg@spider.juniper.net' >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: > >Hi folks, > > > >As I have not got the reply to my mail, I will try and restate(I guess I > >wasn't clear) what the proposal is. > > > >The idea is to have a new TLV called LSP Number TLV, which contains a 32 >bit > >LSP number. The new TLV is propagated in all LSP's and overrides the LSP > >Number field in the header. > > > >To migrate to this scheme, as long as all the routers in the network do not > >support the new TLV, we use the same value in LSP number field in the >header > >as well as the TLV. Once all the routers in the network support the new >TLV, > >we can actually use the value of the LSP number TLV and ignore the LSP > >number field in the header. > > > >The solution in this scheme seems to be a logical extension to the limit > >caused by an 8 bit LSP number field, using a 32 bit sequence number, rather > >than the scheme where we need multiple system id's and then equating the > >ID's. > > > >The advantages of the scheme relative to the other scheme is: - > > > >a) We use a simple migration scheme rather than a two step highly complex > >scheme. > >b) We need not worry about any change to routing table calculations. > >c) No taking care of attached bit. > >d) No taking care of partition bit. > >e) We need not worry about which links use what system id(as in the other > >scheme) and hence a lot of configuration. > >f) The amount of code changes are minimal. > > > >Regarding Mike's comment(I hope I got it right, Mike?) what happens when a > >new router that does not support the functionality comes up. Although the > >assumption with the other drafts like domain-wide and wide metrics is that > >once we migrate to a scheme, we will not try and bother about the older > >scheme, the same problem would occur in the other draft too if a new router > >came up after we had migrated to method 2, and someone did not understand > >the ISIS Alias TLV described there. Routing loops could very easily occur > >there. > >Where do you put the extended numbers in xSNPs? Or are you proposing a new >"extended" LSP entry TLV? What do you do for migration? send both? > >Even if you do this, if you have a router which doesn't understand the new >stuff and you are using the extended number space, you will get perpetual >re-transmission if you have two LSPs with the same "natural" number but >different extended numbers sent to a non-participating router. It will only >ACK one of them. et.c etc. > > Mike > > > >Any comments/criticism invited. > > > >Thanks a lot, > >Vishwas > > > >-----Original Message----- > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > >Sent: Tuesday, April 23, 2002 8:51 PM > >To: 'mike shand' > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >Hi Mike, > > > >Thanks for the reply. > > > >I do not understand if we have migrated to a bigger LSp number, why we >would > >bring in a router that still uses a smaller LSP number, even when we know >it > >could create problems. This problem can occur in all cases of migration > >a) to domain wide > >b) wide metrics > > > >I do not see why we should introduce a two pronged method to do something > >which we can do pretty easily with just a TLV change, when similar > >approaches have been taken for other cases. Even in domain wide if a router > >came in which did not use external reachability in cases of L1 area the >same > >problem would occur. I do not find the reason convincing enough to be > >rejected. ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Tuesday, April 23, 2002 6:13 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >I'm not sure I fully understand this proposal. I assume that when you > >actually start using extended numbers you still need to invent additional > >system ID's for the extra "fragments" so that the update process can > >distinguish them. In which case it is semantically identical to the current > >scheme. > > > >Or are you proposing changing the update process so that it looks at the > >new TLV? I guess that must be what you have in mind. This has fairly > >serious consequences if you have migrated to extended numbers, but you then > >introduce a router which doesn't understand the new update process. I > >thought we had already considered and rejected solutions of this type. > > > > Mike > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > >Hi Amir/Stefano/Mike, > > > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > > >what you thought of it. > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > > >number in the psudonode-id is not used. The changes required are minimum. > >We > > >anyway scan thru TLV's for authentication information, we can find the >LSP > > >number TLV then. We instead use this TLV. > > > > > >To migrate to such a method all we need to do is to, use same LSP numbers > >in > > >the header and the TLV, and once all routers recognize the TLV, we >actually > > >can use different numbers. This does not create any backward >compatibility > > >issues and so we dont need two methods. In this case we do not need to > >worry > > >about Attached bit, Partition repair bit or change to SPF calculations >etc. > > >The solution also seems a logical extension, to the constraint caused by >8 > > >bit LSP number value. Rather than a solution that has multiple system >id's > > >which is like fooling the IS to believe all the systems are the same. > > > > > >Thanks, > > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 03:54:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28715 for ; Thu, 25 Apr 2002 03:54:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P7cot25068; Thu, 25 Apr 2002 00:38:50 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3P7GJt24901 for ; Thu, 25 Apr 2002 00:16:19 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJA6W>; Thu, 25 Apr 2002 03:29:40 -0400 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 03:29:31 -0400 Maybe we could get someone elses views too, of what they feel. That would help. ;-) The idea of extended option in IIH is good, and may be nice for the exp_lsp_fragment draft too(and same with domain wide etc too). Thanks again, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Thursday, April 25, 2002 12:47 PM To: Manral, Vishwas Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt At 02:46 25/04/2002 -0400, Manral, Vishwas wrote: >Hi Mike, > >I actually thought over it, and simplified things a bit further, so that we >never have to send both entry TLV's at one time. > >1. All routers use small LSP numbers at init time. >2. As routers with new functionality come up, they need to send the same >value in header and TLV LSP numbers. They need to be ready to accept the >"extended LSP entry TLV. We however still send the old LSP entry TLV. >3. Once all routers have the capability, we start using different values in >LSP number in the header and the TLV(extended LSP number) and use only >extended LSP entry TLV. I think you need a multi stage migration process. 1. Deploy new software everywhere which understands the new TLVs, and sends the same LSP number in both the LSP header and the extended TLV, but still only sends the old LSP entry TLV. 2. Once you have all routers with the new software, you can go to each router in turn and tell it to use new LSP entries instead of old. 3. Once you have all routers doing this, you can start using extended LSP numbers (i.e. different values in the TLV and the header). It would probably be wise to include some capability bits in the IIHs to prevent forming adjacencies with old routers once you have started using extended LSP numbers. But, note that this is a complex process and requires changes to all the update process code AND the SPF process code to recognize the additional LSP numbers, AND the hello processing code (if we want to make it reasonably safe). I'd MUCH rather confine the changes to the SPF. Mike >Does this sound ok? ;-) > >Thanks, >Vishwas > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Wednesday, April 24, 2002 7:55 PM >To: Manral, Vishwas >Cc: 'isis-wg@spider.juniper.net' >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: > >Hi folks, > > > >As I have not got the reply to my mail, I will try and restate(I guess I > >wasn't clear) what the proposal is. > > > >The idea is to have a new TLV called LSP Number TLV, which contains a 32 >bit > >LSP number. The new TLV is propagated in all LSP's and overrides the LSP > >Number field in the header. > > > >To migrate to this scheme, as long as all the routers in the network do not > >support the new TLV, we use the same value in LSP number field in the >header > >as well as the TLV. Once all the routers in the network support the new >TLV, > >we can actually use the value of the LSP number TLV and ignore the LSP > >number field in the header. > > > >The solution in this scheme seems to be a logical extension to the limit > >caused by an 8 bit LSP number field, using a 32 bit sequence number, rather > >than the scheme where we need multiple system id's and then equating the > >ID's. > > > >The advantages of the scheme relative to the other scheme is: - > > > >a) We use a simple migration scheme rather than a two step highly complex > >scheme. > >b) We need not worry about any change to routing table calculations. > >c) No taking care of attached bit. > >d) No taking care of partition bit. > >e) We need not worry about which links use what system id(as in the other > >scheme) and hence a lot of configuration. > >f) The amount of code changes are minimal. > > > >Regarding Mike's comment(I hope I got it right, Mike?) what happens when a > >new router that does not support the functionality comes up. Although the > >assumption with the other drafts like domain-wide and wide metrics is that > >once we migrate to a scheme, we will not try and bother about the older > >scheme, the same problem would occur in the other draft too if a new router > >came up after we had migrated to method 2, and someone did not understand > >the ISIS Alias TLV described there. Routing loops could very easily occur > >there. > >Where do you put the extended numbers in xSNPs? Or are you proposing a new >"extended" LSP entry TLV? What do you do for migration? send both? > >Even if you do this, if you have a router which doesn't understand the new >stuff and you are using the extended number space, you will get perpetual >re-transmission if you have two LSPs with the same "natural" number but >different extended numbers sent to a non-participating router. It will only >ACK one of them. et.c etc. > > Mike > > > >Any comments/criticism invited. > > > >Thanks a lot, > >Vishwas > > > >-----Original Message----- > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > >Sent: Tuesday, April 23, 2002 8:51 PM > >To: 'mike shand' > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >Hi Mike, > > > >Thanks for the reply. > > > >I do not understand if we have migrated to a bigger LSp number, why we >would > >bring in a router that still uses a smaller LSP number, even when we know >it > >could create problems. This problem can occur in all cases of migration > >a) to domain wide > >b) wide metrics > > > >I do not see why we should introduce a two pronged method to do something > >which we can do pretty easily with just a TLV change, when similar > >approaches have been taken for other cases. Even in domain wide if a router > >came in which did not use external reachability in cases of L1 area the >same > >problem would occur. I do not find the reason convincing enough to be > >rejected. ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Tuesday, April 23, 2002 6:13 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >I'm not sure I fully understand this proposal. I assume that when you > >actually start using extended numbers you still need to invent additional > >system ID's for the extra "fragments" so that the update process can > >distinguish them. In which case it is semantically identical to the current > >scheme. > > > >Or are you proposing changing the update process so that it looks at the > >new TLV? I guess that must be what you have in mind. This has fairly > >serious consequences if you have migrated to extended numbers, but you then > >introduce a router which doesn't understand the new update process. I > >thought we had already considered and rejected solutions of this type. > > > > Mike > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > >Hi Amir/Stefano/Mike, > > > > > >I read thru ur draft and had an alternate idea in mind. I wanted to know > > >what you thought of it. > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: - > > > > > >The idea is to have a new TLV, which tells the actual LSP number. The LSP > > >number in the psudonode-id is not used. The changes required are minimum. > >We > > >anyway scan thru TLV's for authentication information, we can find the >LSP > > >number TLV then. We instead use this TLV. > > > > > >To migrate to such a method all we need to do is to, use same LSP numbers > >in > > >the header and the TLV, and once all routers recognize the TLV, we >actually > > >can use different numbers. This does not create any backward >compatibility > > >issues and so we dont need two methods. In this case we do not need to > >worry > > >about Attached bit, Partition repair bit or change to SPF calculations >etc. > > >The solution also seems a logical extension, to the constraint caused by >8 > > >bit LSP number value. Rather than a solution that has multiple system >id's > > >which is like fooling the IS to believe all the systems are the same. > > > > > >Thanks, > > >Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 08:34:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03380 for ; Thu, 25 Apr 2002 08:34:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PCI2t26872; Thu, 25 Apr 2002 05:18:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PCHCt26860 for ; Thu, 25 Apr 2002 05:17:12 -0700 (PDT) (envelope-from ruwhite@cisco.com) Received: from uzura.cisco.com (uzura.cisco.com [64.102.17.77]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA01460; Thu, 25 Apr 2002 08:30:33 -0400 (EDT) From: Russ White Reply-To: Russ White To: mike shand cc: Naiming Shen , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft In-Reply-To: <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 08:30:33 -0400 (EDT) > I think, given the various scenarios, we need a bit of > flexibility here. My intent was that the whole thing was > "fail safe". i.e. if the restarting router didn't come back > up properly, the neighbors would drop their adjacencies as if > it had just plain failed. I didn't want the restarting to > delay the normal recovery. > > However, I understand that some implementations may not be > able to get back up within this time, especially for short > hello times, and that some measure of "hello I'm back, could > you just give me a little extra time to get my act together" > would be helpful. I like Nischal's suggestion here. Agreed.... It's better to assume that since we've received a hello with the proper bits set, we should give the adjacent is a little more time. > > not meant to be bullet proof. If the IIHs happen to get lost, > > we just have a bad day. This is also the same problem if you > > have multiple neighbors on the same LAN. Your IIH can be lost > > to one of the neighbors, but as soon as you receive from > > other neighbors and complete the CSNPs, the T1 will be cancelled. > > But you have no way to know, that one neighbor didn't > > receive your re-start IIH, and it will reset the adjacency. > > The current scheme does not cover that case, and I think its > > not worth to have retries in general. Thus actually we don't > > even need the T1. > > I'm not sure. I didn't like the idea that we may be stalled > waiting for multiple retries, but OTOH it goes against the > grain to design a protocol which "fails" on the loss of a > single packet :-) > > I guess the question is how many times will we sit around > waiting for a response when we will never get one, as opposed > to the times when we genuinely loose a packet and this allows > us to re-start when we otherwise wouldn't. We could prescribe a smaller number of retries, perhaps. I don't like the idea of dropping a single packet causing the restart to fail, either. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 09:11:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04695 for ; Thu, 25 Apr 2002 09:11:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PCtit27078; Thu, 25 Apr 2002 05:55:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PCpgt27052 for ; Thu, 25 Apr 2002 05:51:42 -0700 (PDT) (envelope-from wangxp@huawei.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3PD5A680042 for ; Thu, 25 Apr 2002 06:05:10 -0700 (PDT) X-JNPR-Received-From: outside Received: from smtp.huawei.com ([61.144.161.21]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 05:44:07 -0700 Received: from wangxuepu29436 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GV4JCA00.LHD for ; Thu, 25 Apr 2002 20:43:22 +0800 Message-ID: <000f01c1ede9$3d485d00$3b336e0a@HUAWEI.COM> From: "Wang xuepu" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1EE2C.4B20D860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 25 Apr 2002 12:44:08.0406 (UTC) FILETIME=[E4438F60:01C1EC56] Subject: [Isis-wg] About MTU? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 27 Apr 2002 20:44:14 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1EE2C.4B20D860 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9zZSB0aGVyZSBhcmUgdGhyZWUgcm91dGVycyBpbiB0aGUgc2FtZSBhcmVhLGFuZCB0aGV5 IGFyZSBjb25uZWN0ZWQgYnkgdGhlIGV0aGVybmV0Lg0Kc3VjaCBhczoNCg0KIF9fXyAgICAgICAg X19fICAgICAgICAgX19fICAgIA0KfCBBIHxfX19fX198IEIgfF9fX19fX198IEMgfCANCnxfX198 ZTAgIGUwfF9fX3xlMSAgIGUwfF9fX3wNCiAgICAgICANClN1cHBvc2U6DQpSb3V0ZXIgQTogDQog ICAgICAgICB0aGUgbXR1IG9mIGUwIGlzIDE1MDAuDQpSb3V0ZXIgQjoNCiAgICAgICAgIHRoZSBt dHUgb2YgZTAgaXMgMTUwMC4gICAgDQogICAgICAgICB0aGUgbXR1IG9mIGUxIGlzIDEwMDAuICAg IA0KUm91dGVyIEM6DQogICAgICAgICB0aGUgbXR1IG9mIGUwIGlzIDEwMDAuICAgIA0KTm93Og0K V2hlbiBSb3V0ZXIgQiByZWNlaXZlIGEgUm91dGVyIEEncyBMU1AgZnJvbSBlMCx0aGUgc2l6ZSBv ZiB0aGlzIExTUCBzaG91bGQgYmUgMTUwMCx0aGUgUm91dGVyIEIgc2hvdWxkIGZsb29kDQp0aGUg TFNQLGJ1dCBCIGNhbiBub3Qgc2VuZCB0aGlzIExTUCB0aHJvdWdodCBlMS5iZWNhc2UgdGhlIG10 dSBpcyB0b28gc21hbGwuDQpJcyBpdCBjb3JyZWN0Pw0KaWYgaXQgaXMgcmlnaHQsaG93IGNhbiB3 ZSBzb2x1dGUgdGhpcyBwcm9ibGVtPw0KDQo= ------=_NextPart_000_000C_01C1EE2C.4B20D860 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMzE0LjIxMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5TdXBwb3NlIHRoZXJlIGFy ZSB0aHJlZSByb3V0ZXJzIGluIHRoZSBzYW1lIGFyZWEsYW5kIHRoZXkgYXJlIA0KY29ubmVjdGVk IGJ5IHRoZSBldGhlcm5ldC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5zdWNoIGFz OjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz cDtfX18mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpfX18mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fJm5ic3A7Jm5i c3A7Jm5ic3A7IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+fCBBIHxfX19fX198 IEIgfF9fX19fX198Jm5ic3A7QyB8IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+ fF9fX3xlMCZuYnNwOyZuYnNwO2UwfF9fX3xlMSZuYnNwOyZuYnNwOyZuYnNwO2UwfF9fX3w8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U3VwcG9zZTo8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Sb3V0ZXIgQTogPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UwIGlzIDE1MDAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+Um91dGVyIEI6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3RoZSBtdHUgDQpvZiZu YnNwO2UwIGlzJm5ic3A7MTUwMC4mbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UxIGlzJm5ic3A7MTAwMC4mbmJzcDsmbmJzcDsmbmJz cDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Um91dGVyIEM6PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UwIGlzJm5ic3A7MTAwMC4mbmJzcDsmbmJz cDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Tm93OjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPldoZW4gUm91dGVyIEIgcmVjZWl2ZSBhIFJvdXRlciBBJ3Mg TFNQIGZyb20gZTAsdGhlIHNpemUgb2YgDQp0aGlzIExTUCBzaG91bGQgYmUgMTUwMCx0aGUgUm91 dGVyIEIgc2hvdWxkIGZsb29kPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGhlIExT UCxidXQgQiBjYW4gbm90IHNlbmQgdGhpcyBMU1AgdGhyb3VnaHQgZTEuYmVjYXNlIHRoZSBtdHUg DQppcyB0b28gc21hbGwuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgaXQgY29y cmVjdD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pZiBpdCBpcyByaWdodCxob3cg Y2FuIHdlIHNvbHV0ZSB0aGlzIHByb2JsZW0/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000C_01C1EE2C.4B20D860-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 10:23:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06993 for ; Thu, 25 Apr 2002 10:23:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PE5Qt27427; Thu, 25 Apr 2002 07:05:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PDvIt27381 for ; Thu, 25 Apr 2002 06:57:18 -0700 (PDT) (envelope-from rja@extremenetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PEAkn98557 for ; Thu, 25 Apr 2002 07:10:46 -0700 (PDT) X-JNPR-Received-From: outside Received: from gnat.inet.org ([63.108.254.91]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 06:48:57 -0700 Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id B4D8467103; Thu, 25 Apr 2002 10:18:55 -0400 (EDT) Subject: Re: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'Radia Perlman - Boston Center for Networking'" , isis-wg@juniper.net To: Jeff Parker From: RJ Atkinson In-Reply-To: Message-Id: <769E9C5B-5853-11D6-AD10-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-OriginalArrivalTime: 25 Apr 2002 13:48:57.0390 (UTC) FILETIME=[F2476CE0:01C1EC5F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 09:50:54 -0400 Content-Transfer-Encoding: 7bit On Wednesday, April 24, 2002, at 06:00 , Jeff Parker wrote: >> Does the MIB allow setting multiple receive secrets? >> >> Radia > > In the past the MIB discussed authentication, but I was > asked to remove it to improve security. Letting the MIB add/delete/view/modify any of the cryptographic keys (or whether cryptography is enabled) is a very very bad idea -- creates a cascading security vulnerability. Ran _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 11:00:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08410 for ; Thu, 25 Apr 2002 11:00:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PEjBt27645; Thu, 25 Apr 2002 07:45:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PEaHt27590 for ; Thu, 25 Apr 2002 07:36:17 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'RJ Atkinson'" Cc: "IS-IS-WG (E-mail)" Subject: [Isis-wg] *SNP replay MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 10:11:11 -0400 Just to be clear I have removed the draft name from the subject line. > > I'm not suggesting we delay the document. > > > So a robust IS-IS implementation probably won't be very badly > affected by packet replay. For non-robust implementations, > any number of things could be a problem -- but that is an > implementation quality issue IMHO. True. I hope that improving implementation quality is something worth discussing on this list. What is interesting about replaying *SNP packets is that it is one of the few ways in ISIS to introduce a multiplier. The worst of the DOS attack depend upon other machines doing the work, and an out of date *SNP will cause other machines to retransmit LSPs. I agree that there are rate limits on how fast you resend an LSP, but with a large configuration, SNPs with stale info could force constant updates. (The only other packet I can think of with leverage is changing the priority on a hello to force a DIS election. If I send a duplicate of a hello from a low-status IS with high priority, can't I force all of the machines on a network to swing back and forth between two DISs?) - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 12:08:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25311 for ; Thu, 25 Apr 2002 12:08:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PFcFt27919; Thu, 25 Apr 2002 08:38:15 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PFMGt27837 for ; Thu, 25 Apr 2002 08:22:16 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PFZjn00141 for ; Thu, 25 Apr 2002 08:35:45 -0700 (PDT) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 08:11:55 -0700 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PFEDF7007272; Thu, 25 Apr 2002 11:14:14 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-466.cisco.com [10.82.241.210]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABH34015; Thu, 25 Apr 2002 11:13:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20020425110929.024318c8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Wang xuepu" From: Jeff Learman Subject: Re: [Isis-wg] About MTU? Cc: In-Reply-To: <000f01c1ede9$3d485d00$3b336e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_97632267==_.ALT" X-OriginalArrivalTime: 25 Apr 2002 15:11:55.0327 (UTC) FILETIME=[895C54F0:01C1EC6B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 11:13:12 -0400 --=====================_97632267==_.ALT Content-Type: text/plain; charset="us-ascii" ISO 10589:1992 is not clear what should be done in this case -- the answer seems to be to purge the PDU. ISO 10589:2001 clears up what the router should do, but it doesn't solve the problem -- it just makes the problem less severe and defines management events to help indicate the existence of the problem. It's a configuration error, and the network administrator must fix it by reducing the maximum originate LSP size on all routers in the subdomain (area or L2 backbone). Regards, Jeff At 08:44 AM 4/27/2002, Wang xuepu wrote: >Suppose there are three routers in the same area,and they are connected by the ethernet. >such as: > > ___ ___ ___ >| A |______| B |_______| C | >|___|e0 e0|___|e1 e0|___| > >Suppose: >Router A: > the mtu of e0 is 1500. >Router B: > the mtu of e0 is 1500. > the mtu of e1 is 1000. >Router C: > the mtu of e0 is 1000. >Now: >When Router B receive a Router A's LSP from e0,the size of this LSP should be 1500,the Router B should flood >the LSP,but B can not send this LSP throught e1.becase the mtu is too small. >Is it correct? >if it is right,how can we solute this problem? > --=====================_97632267==_.ALT Content-Type: text/html; charset="us-ascii"
ISO 10589:1992 is not clear what should be done in this case -- the
answer seems to be to purge the PDU.

ISO 10589:2001 clears up what the router should do, but it doesn't
solve the problem -- it just makes the problem less severe and defines
management events to help indicate the existence of the problem.

It's a configuration error, and the network administrator must fix it
by reducing the maximum originate LSP size on all routers in the
subdomain (area or L2 backbone).

Regards,
Jeff

At 08:44 AM 4/27/2002, Wang xuepu wrote:
Suppose there are three routers in the same area,and they are connected by the ethernet.
such as:
 
 ___        ___         ___   
| A |______| B |_______| C |
|___|e0  e0|___|e1   e0|___|
      
Suppose:
Router A:
         the mtu of e0 is 1500.
Router B:
         the mtu of e0 is 1500.   
         the mtu of e1 is 1000.   
Router C:
         the mtu of e0 is 1000.   
Now:
When Router B receive a Router A's LSP from e0,the size of this LSP should be 1500,the Router B should flood
the LSP,but B can not send this LSP throught e1.becase the mtu is too small.
Is it correct?
if it is right,how can we solute this problem?
 
--=====================_97632267==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 12:27:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26328 for ; Thu, 25 Apr 2002 12:27:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PGBvt28097; Thu, 25 Apr 2002 09:11:57 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PFoqt27970 for ; Thu, 25 Apr 2002 08:50:52 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PG48n00904 for ; Thu, 25 Apr 2002 09:04:21 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 08:33:23 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id IAA03606; Thu, 25 Apr 2002 08:35:18 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G8NL44>; Thu, 25 Apr 2002 08:35:17 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F98A@avalon.pluris.com> From: Les Ginsberg To: "'Wang xuepu '" , "'isis-wg@juniper.net '" Subject: RE: [Isis-wg] About MTU? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="GB2312" X-OriginalArrivalTime: 25 Apr 2002 15:33:23.0125 (UTC) FILETIME=[88F2B650:01C1EC6E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 08:35:17 -0700 The short answer is that you must configure the maximum LSP size that any router in the area/domain will generate to be no larger than the smallest MTU of any link in the area/domain that will be used for propagation - in your example originatingLxLSPSize must be set to 997 (1000 - 3 bytes for LLC1 header) on all routers. The longer answer can be found at: ftp://ftp.juniper.net/pub/isis/lspsize.PDF This solution has been incorporated into the ISO 10589:2001 draft. Les -----Original Message----- From: Wang xuepu To: isis-wg@juniper.net Sent: 4/27/02 5:44 AM Subject: [Isis-wg] About MTU? Suppose there are three routers in the same area,and they are connected by the ethernet. such as: ___ ___ ___ | A |______| B |_______| C | |___|e0 e0|___|e1 e0|___| Suppose: Router A: the mtu of e0 is 1500. Router B: the mtu of e0 is 1500. the mtu of e1 is 1000. Router C: the mtu of e0 is 1000. Now: When Router B receive a Router A's LSP from e0,the size of this LSP should be 1500,the Router B should flood the LSP,but B can not send this LSP throught e1.becase the mtu is too small. Is it correct? if it is right,how can we solute this problem? _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 13:51:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29291 for ; Thu, 25 Apr 2002 13:51:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PHZot28512; Thu, 25 Apr 2002 10:35:50 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PHBft28399 for ; Thu, 25 Apr 2002 10:11:41 -0700 (PDT) (envelope-from Ravindra.Sunkad@VivaceNetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PHPAn03331 for ; Thu, 25 Apr 2002 10:25:10 -0700 (PDT) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 09:46:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EC79.21D797D3" Subject: RE: [Isis-wg] About MTU? Message-ID: Thread-Topic: [Isis-wg] About MTU? Thread-Index: AcHsd7d3SgQxFlkiRt6MRtB7cjVUYAAABCGA From: "Ravindra Sunkad" To: "Jeff Learman" , "Wang xuepu" Cc: X-OriginalArrivalTime: 25 Apr 2002 16:46:42.0078 (UTC) FILETIME=[C6EDABE0:01C1EC78] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 09:49:14 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1EC79.21D797D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If an implementation brings down IS-IS on interfaces with MTU < LSP_BUF_SIZE this problem will not arise. =20 -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com]=20 Sent: Thursday, April 25, 2002 8:13 AM To: Wang xuepu Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] About MTU? =09 ISO 10589:1992 is not clear what should be done in this case -- the answer seems to be to purge the PDU. =09 ISO 10589:2001 clears up what the router should do, but it doesn't solve the problem -- it just makes the problem less severe and defines management events to help indicate the existence of the problem. =09 It's a configuration error, and the network administrator must fix it by reducing the maximum originate LSP size on all routers in the subdomain (area or L2 backbone). =09 Regards, Jeff =09 At 08:44 AM 4/27/2002, Wang xuepu wrote: =09 Suppose there are three routers in the same area,and they are connected by the ethernet. such as: =20 ___ ___ ___ =20 | A |______| B |_______| C |=20 |___|e0 e0|___|e1 e0|___| =20 Suppose: Router A:=20 the mtu of e0 is 1500. Router B: the mtu of e0 is 1500. =20 the mtu of e1 is 1000. =20 Router C: the mtu of e0 is 1000. =20 Now: When Router B receive a Router A's LSP from e0,the size of this LSP should be 1500,the Router B should flood the LSP,but B can not send this LSP throught e1.becase the mtu is too small. Is it correct? if it is right,how can we solute this problem? =20 ------_=_NextPart_001_01C1EC79.21D797D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
If an=20 implementation brings down IS-IS on interfaces with MTU <=20 LSP_BUF_SIZE this problem will not arise.
 
-----Original = Message-----
From: Jeff=20 Learman [mailto:jlearman@cisco.com]
Sent: Thursday, April 25, = 2002=20 8:13 AM
To: Wang xuepu
Cc:=20 isis-wg@juniper.net
Subject: Re: [Isis-wg] About=20 MTU?


ISO 10589:1992 is not = clear what=20 should be done in this case -- the
answer seems to be to purge the=20 PDU.

ISO 10589:2001 clears up what the router should do, but it = doesn't
solve the problem -- it just makes the problem less severe = and=20 defines
management events to help indicate the existence of the=20 problem.

It's a configuration error, and the network = administrator must=20 fix it
by reducing the maximum originate LSP size on all routers in = the
subdomain (area or L2 = backbone).

Regards,
Jeff

At=20 08:44 AM 4/27/2002, Wang xuepu wrote:
Suppose there are three = routers in=20 the same area,and they are connected by the = ethernet.
such as:
 
 ___       =20 ___         = ___   =20
| A |______| B |_______| C | =
|___|e0  e0|___|e1   e0|___|
      
Suppose:
Router A: =
         the mtu of = e0 is=20 1500.
Router B:
         the mtu of = e0 is=20 1500.   
         the mtu of = e1 is=20 1000.   
Router = C:
         the mtu of = e0 is=20 1000.   
Now:
When Router B receive a Router A's LSP from e0,the size of = this LSP=20 should be 1500,the Router B should flood
the LSP,but=20 B can not send this LSP throught e1.becase the mtu is too=20 small.
Is it correct?
if it is=20 right,how can we solute this=20 problem?
 
=00 ------_=_NextPart_001_01C1EC79.21D797D3-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 15:24:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03022 for ; Thu, 25 Apr 2002 15:24:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PIp1t28913; Thu, 25 Apr 2002 11:51:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PIoPt28901 for ; Thu, 25 Apr 2002 11:50:25 -0700 (PDT) (envelope-from ramsrm@tdd.sj.nec.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PJ3sn06352 for ; Thu, 25 Apr 2002 12:03:54 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 11:50:18 -0700 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g3PIqGK20605 for ; Thu, 25 Apr 2002 11:52:16 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id LAA27139 for ; Thu, 25 Apr 2002 11:52:09 -0700 (PDT) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g3PIkaX18742 for ; Thu, 25 Apr 2002 11:46:36 -0700 (PDT) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.11.3/8.11.6) with SMTP id g3PIkZg09176 for ; Thu, 25 Apr 2002 11:46:35 -0700 (PDT) Received: by localhost with Microsoft MAPI; Thu, 25 Apr 2002 11:54:11 -0700 Message-ID: <01C1EC4F.E9EE88E0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "isis-wg@juniper.net" Organization: NEC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 23 TEXT X-OriginalArrivalTime: 25 Apr 2002 18:50:18.0733 (UTC) FILETIME=[0B9969D0:01C1EC8A] Subject: [Isis-wg] authentication. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 11:54:10 -0700 Hi all, I have a doubt in ISIS. could u please explain me? In ISIS we have authentication TLV. There is no restriction on this TLV whether to come in the front or not. so it can come in any place in all pdus( hello/LSP). So a receiver of the PDU has to go thro' the entire packet to reach to the authentication TLV and then check whether the authentication condition is satisfied or not. But it seems to me a big overhead, we need to scan the complete packet or to the point where that TLV is available. is there any reason behind this(i.e having the authentication TLV at any position, usually at the end)?. Generally we have checksum computation, that involves going thro' the whole packet and finally that result will be put in the packet header, so that receiving end can easily get the value and check it. similarly why not we can have a restriction that the Authentication TLV shud appear before all the TLVs so that processing will be easier. thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 15:52:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03978 for ; Thu, 25 Apr 2002 15:52:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PJb1t29129; Thu, 25 Apr 2002 12:37:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PJaet29117 for ; Thu, 25 Apr 2002 12:36:40 -0700 (PDT) (envelope-from zinin@psg.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PJoAn07363 for ; Thu, 25 Apr 2002 12:50:10 -0700 (PDT) X-JNPR-Received-From: outside Received: from psg.com ([147.28.0.62]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 12:45:19 -0700 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 170pD2-000JSJ-00; Thu, 25 Apr 2002 12:47:16 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <44105465351.20020425124647@psg.com> To: ramanathan rams CC: "isis-wg@juniper.net" Subject: Re: [Isis-wg] authentication. In-Reply-To: <01C1EC4F.E9EE88E0.ramsrm@tdd.sj.nec.com> References: <01C1EC4F.E9EE88E0.ramsrm@tdd.sj.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2002 19:45:20.0202 (UTC) FILETIME=[BB6D9AA0:01C1EC91] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 12:46:47 -0700 Content-Transfer-Encoding: 7bit Ramanathan, I brought this up a while ago. If we were sure that _all_ implementations already do put the Auth TLV at the beginning or at the end, one could take advantage of this. However, there seems to be no confidence in this, so you still have to be ready for the case where the TLV can appear anywhere in the PDU, and hence you don't really gain anything. -- Alex Thursday, April 25, 2002, 11:54:10 AM, you wrote: > Hi all, > I have a doubt in ISIS. could u please explain me? > In ISIS we have authentication TLV. There is no restriction on this > TLV whether to come in the front or not. so it can come in any place in all > pdus( hello/LSP). > So a receiver of the PDU has to go thro' the entire packet to reach > to the authentication TLV and then check whether the authentication > condition is satisfied or not. But it seems to me a big overhead, we need > to scan the complete packet or to the point where that TLV is available. is > there any reason behind this(i.e having the authentication TLV at any > position, usually at the end)?. > Generally we have checksum computation, that involves going thro' > the whole packet and finally that result will be put in the packet header, > so that receiving end can easily get the value and check it. similarly why > not we can have a restriction that the Authentication TLV shud appear > before all the TLVs so that processing will be easier. > thanks > rams. > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 16:30:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05016 for ; Thu, 25 Apr 2002 16:30:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PKEit29322; Thu, 25 Apr 2002 13:14:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3PKAqt29297 for ; Thu, 25 Apr 2002 13:10:52 -0700 (PDT) (envelope-from jparker@axiowave.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3PKOLn08289 for ; Thu, 25 Apr 2002 13:24:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 13:10:48 -0700 Message-ID: From: Jeff Parker To: "'ramsrm@tdd.sj.nec.com'" , isis-wg@juniper.net Subject: RE: [Isis-wg] authentication. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Apr 2002 20:10:49.0092 (UTC) FILETIME=[4AB7B440:01C1EC95] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 16:12:27 -0400 > why not we can have a restriction that the Authentication > TLV shud appear before all the TLVs so that processing > will be easier. > > thanks > rams. It is probably time to quote "Be conservative in what you send and liberal in what you recieve" Since you cannot count on the other side to put the TLV in the right spot, you need to include the logic to find it anywhere. Perhaps we should add "and Libertarian in what you require others to do" - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 23:15:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14454 for ; Thu, 25 Apr 2002 23:15:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q2x2t30930; Thu, 25 Apr 2002 19:59:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q2wKt30908 for ; Thu, 25 Apr 2002 19:58:20 -0700 (PDT) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3Q3Bqn14915 for ; Thu, 25 Apr 2002 20:11:52 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 19:18:00 -0700 Received: from redback.com ([63.200.51.103]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV500EUFL5CRP@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 25 Apr 2002 19:20:00 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] About MTU? To: Ravindra Sunkad Cc: Jeff Learman , Wang xuepu , isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CC8A7E9.E759A617@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: X-OriginalArrivalTime: 26 Apr 2002 02:18:00.0702 (UTC) FILETIME=[969499E0:01C1ECC8] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 18:05:46 -0700 Content-Transfer-Encoding: 7BIT Ravindra Sunkad wrote: > If an implementation brings down IS-IS on interfaces with MTU < LSP_BUF_SIZE this problem > will not arise. > > > not good enough, the problem is transitive, you may have interface with MTU 4096, > your LSP_BUF_SIZE is 1024 > and you receive from your neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048 > > -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 23:20:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14507 for ; Thu, 25 Apr 2002 23:20:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q35Ft30983; Thu, 25 Apr 2002 20:05:15 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q2wpt30918 for ; Thu, 25 Apr 2002 19:58:51 -0700 (PDT) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3Q3CNn15046 for ; Thu, 25 Apr 2002 20:12:23 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 19:33:15 -0700 Received: from redback.com ([63.200.51.103]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV500D6GLUR1N@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 25 Apr 2002 19:35:15 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] About MTU? To: Ravindra Sunkad Cc: Jeff Learman , Wang xuepu , isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CC8AB7D.ADB6C864@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: X-OriginalArrivalTime: 26 Apr 2002 02:33:16.0046 (UTC) FILETIME=[B82B02E0:01C1ECCA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 18:21:01 -0700 Content-Transfer-Encoding: 7BIT Ravindra Sunkad wrote: > True. But, LSP acceptance tests in 10589 already take care of this case. either you or me seems confused here? You make a statement taht does not seem to be 100% true and when I correct it, you go off on a tangent?? The problem mentioned in the mail at the beginning of this thread is real, the solutions given by Jeff & Les are here with pros & cons and what you said was at best only partially true -=-= tony > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Thursday, April 25, 2002 6:06 PM > > To: Ravindra Sunkad > > Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net > > Subject: Re: [Isis-wg] About MTU? > > > > > > Ravindra Sunkad wrote: > > > > > If an implementation brings down IS-IS on interfaces with MTU < > > > LSP_BUF_SIZE this problem will not arise. > > > > > > > > > not good enough, the problem is transitive, you may have interface > > > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive from your > > > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048 > > > > > > -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Apr 25 23:28:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14604 for ; Thu, 25 Apr 2002 23:28:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q3Cht31041; Thu, 25 Apr 2002 20:12:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q361t30993 for ; Thu, 25 Apr 2002 20:06:01 -0700 (PDT) (envelope-from Ravindra.Sunkad@VivaceNetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3Q3JWn15700 for ; Thu, 25 Apr 2002 20:19:32 -0700 (PDT) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 19:25:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] About MTU? Message-ID: Thread-Topic: [Isis-wg] About MTU? Thread-Index: AcHsyPP8JisHArKaR1u0OOfxuMChJQAAHQMg From: "Ravindra Sunkad" To: Cc: "Jeff Learman" , "Wang xuepu" , X-OriginalArrivalTime: 26 Apr 2002 02:25:21.0796 (UTC) FILETIME=[9D7E3440:01C1ECC9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3Q361t30994 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 19:27:38 -0700 Content-Transfer-Encoding: 8bit True. But, LSP acceptance tests in 10589 already take care of this case. > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Thursday, April 25, 2002 6:06 PM > To: Ravindra Sunkad > Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net > Subject: Re: [Isis-wg] About MTU? > > > Ravindra Sunkad wrote: > > > If an implementation brings down IS-IS on interfaces with MTU < > > LSP_BUF_SIZE this problem will not arise. > > > > > > not good enough, the problem is transitive, you may have interface > > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive from your > > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048 > > > > -- tony > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 00:36:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16081 for ; Fri, 26 Apr 2002 00:36:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q4K1t31371; Thu, 25 Apr 2002 21:20:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q4Jgt31356 for ; Thu, 25 Apr 2002 21:19:46 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3Q4XA696676 for ; Thu, 25 Apr 2002 21:33:14 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 20:48:24 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA21527; Thu, 25 Apr 2002 20:50:00 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G8NN6N>; Thu, 25 Apr 2002 20:50:00 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F992@avalon.pluris.com> From: Les Ginsberg To: "'Ravindra Sunkad'" , prz@redback.com Cc: Jeff Learman , Wang xuepu , isis-wg@juniper.net Subject: RE: [Isis-wg] About MTU? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Apr 2002 03:48:24.0921 (UTC) FILETIME=[37AABC90:01C1ECD5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 20:49:59 -0700 Tony is quite right. The protocol has no way to prevent this problem completely, since configuration must be consistent throughout the area/domain - not just with your neighbors. Checks when bringing up an adjacency help, but do not eliminate the problem - and the extensions added into ISO 10589:2001 do not prevent the problem either - though if used area/domain wide they will detect and report misconfigurations - in some cases before propagation failures actually occur. It is still up to the network administrator to correct the misconfiguration. Les > > > True. But, LSP acceptance tests in 10589 already take care of > this case. > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Thursday, April 25, 2002 6:06 PM > > To: Ravindra Sunkad > > Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net > > Subject: Re: [Isis-wg] About MTU? > > > > > > Ravindra Sunkad wrote: > > > > > If an implementation brings down IS-IS on interfaces with MTU < > > > LSP_BUF_SIZE this problem will not arise. > > > > > > > > > not good enough, the problem is transitive, you may have > interface > > > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive > from your > > > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is > set to 2048 > > > > > > -- tony > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 02:08:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25686 for ; Fri, 26 Apr 2002 02:08:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q5qit31859; Thu, 25 Apr 2002 22:52:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q5lVt31830 for ; Thu, 25 Apr 2002 22:47:31 -0700 (PDT) (envelope-from selvarajr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3Q614698754 for ; Thu, 25 Apr 2002 23:01:04 -0700 (PDT) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 22:49:16 -0700 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 26 Apr 2002 11:40:11 +0530 Received: from selvarajr (selvarajr.future.futsoft.com [10.4.6.32]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g3Q5oXh21293; Fri, 26 Apr 2002 11:20:33 +0530 Reply-To: From: "SelvarajR" To: , "'Ravindra Sunkad'" Cc: "'Jeff Learman'" , "'Wang xuepu'" , Subject: RE: [Isis-wg] About MTU? Message-Id: <001001c1ece6$b598ae80$2006040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CC8A7E9.E759A617@redback.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2002 05:49:16.0561 (UTC) FILETIME=[19FB3010:01C1ECE6] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Apr 2002 11:23:36 +0530 Content-Transfer-Encoding: 7bit Hi, I guess the latest 10589v2 address this by defining new TLV. But apologies in advance that I'm not well sure about that. The idea is that all the ISIS process in the domain agreeing upon for the least MTU in the domain. All ISIS process should advertise their least interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then, each ISIS process shall scan there LSP data base and select the least MTU among those advertised in the LSP, including its own LSP. This least MTU shall be used as the LSPBufferSize. If there is any change in the current LSPBufferSize then the ISIS process shall restart. For this all the ISIS process should support the new TLV. This mechanism may have quite few number of ISIS process restart as an overhead. No Pain No Gain ;) I guess this may solve the problem. Selva. | -----Original Message----- | From: isis-wg-admin@spider.juniper.net | [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Tony Przygienda | Sent: Friday, 26 April 2002 6:36 AM | To: Ravindra Sunkad | Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net | Subject: Re: [Isis-wg] About MTU? | | | Ravindra Sunkad wrote: | | > If an implementation brings down IS-IS on interfaces with | MTU < LSP_BUF_SIZE this problem | > will not arise. | > | > | > not good enough, the problem is transitive, you may have | interface with MTU 4096, | > your LSP_BUF_SIZE is 1024 | > and you receive from your neighbor an LSP with size 2048 | since his LSP_BUF_SIZE is set to 2048 | > | > -- tony | | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 02:36:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26086 for ; Fri, 26 Apr 2002 02:36:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q6LQt32031; Thu, 25 Apr 2002 23:21:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q6CDt31970 for ; Thu, 25 Apr 2002 23:12:13 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B3FB11DCC6C; Thu, 25 Apr 2002 23:25:45 -0700 (PDT) To: Russ White Cc: mike shand , Naiming Shen , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft In-reply-to: Mail from Russ White dated Thu, 25 Apr 2002 08:30:33 EDT From: Naiming Shen Message-Id: <20020426062545.B3FB11DCC6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 23:25:45 -0700 Hi Russ, ] ] Agreed.... It's better to assume that since we've received a ] hello with the proper bits set, we should give the adjacent is a ] little more time. ] ] > > not meant to be bullet proof. If the IIHs happen to get lost, ] > > we just have a bad day. This is also the same problem if you ] > > have multiple neighbors on the same LAN. Your IIH can be lost ] > > to one of the neighbors, but as soon as you receive from ] > > other neighbors and complete the CSNPs, the T1 will be cancelled. ] > > But you have no way to know, that one neighbor didn't ] > > receive your re-start IIH, and it will reset the adjacency. ] > > The current scheme does not cover that case, and I think its ] > > not worth to have retries in general. Thus actually we don't ] > > even need the T1. ] > ] > I'm not sure. I didn't like the idea that we may be stalled ] > waiting for multiple retries, but OTOH it goes against the ] > grain to design a protocol which "fails" on the loss of a ] > single packet :-) ] > ] > I guess the question is how many times will we sit around ] > waiting for a response when we will never get one, as opposed ] > to the times when we genuinely loose a packet and this allows ] > us to re-start when we otherwise wouldn't. ] ] We could prescribe a smaller number of retries, perhaps. I don't ] like the idea of dropping a single packet causing the restart to ] fail, either. "prescribe" is a little strong for me:-) even though I've nothing against retries. retries, at least the mechanism in the current draft, only solves some easy cases, such as the re-start IIHs get lost on p2p links. Let's see what can happen on a LAN: assume we have routers A, B, C and D on the LAN. A is the re-start router. A sends out a re-start IIH on the LAN, only C and D get it. There is a way for A to know B is on the LAN by looking the re-start ACKs sent back by C and D(assume they didn't get lost). B should be listed as one of the neighbors of C and D. should we retry? - if we don't retry, than its the same "dropping a single packet causing the restart to fail". - if we do try, (a) just send the re-start IIH again on this LAN, then C and D will go through this re-start again. (b) somehow to only inform B to ack on this re-start IIH. we can include systemIDs in the re-start TLV, and have a bit to indicate only below systems need to respond to re-start. - a new mechansim, since C and D all sent re-start Ack, if B sees those Acks, B knows it missed the re-start IIH. it would be equivalent of recv a re-start IIH:-) but it does not know who restarted. - need to do this for both levels. what if B received re-start IIH on level-1 but not level-2? since re-start usually affects both levels, maybe should let level-1 inform the level-2 on B. thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 03:05:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26393 for ; Fri, 26 Apr 2002 03:05:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q6nQt32186; Thu, 25 Apr 2002 23:49:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q6fUt32140 for ; Thu, 25 Apr 2002 23:41:30 -0700 (PDT) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.51.103]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV5006A7XVQRI@mta6.snfc21.pbi.net> for isis-wg@spider.juniper.net; Thu, 25 Apr 2002 23:55:02 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] *SNP replay To: Jeff Parker Cc: "'RJ Atkinson'" , "IS-IS-WG (E-mail)" Message-id: <3CC9027E.4060400@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Apr 2002 00:32:14 -0700 Content-Transfer-Encoding: 7BIT > > >>So a robust IS-IS implementation probably won't be very badly >>affected by packet replay. For non-robust implementations, >>any number of things could be a problem -- but that is an >>implementation quality issue IMHO. >> > >True. I hope that improving implementation quality >is something worth discussing on this list. > yes, to some extent, but it shouldn't be or become this list main activity, we are about interoperating implementations, we are not in business of protecting people from themselves or helping people build businesses ;-) >What is interesting about replaying *SNP packets is >that it is one of the few ways in ISIS to introduce >a multiplier. The worst of the DOS attack depend >upon other machines doing the work, and an out of >date *SNP will cause other machines to retransmit >LSPs. I agree that there are rate limits on how >fast you resend an LSP, but with a large configuration, >SNPs with stale info could force constant updates. > yes, also corrupted SNPs can lead to interesting effects, e.g. just sending large SNPs full of rubish can lead to many routers running around trying to find out what's going on ;-) Few package but large damage, I think that's the metric you are alluring to ;-) >(The only other packet I can think of with leverage >is changing the priority on a hello to force a >DIS election. If I send a duplicate of a hello >from a low-status IS with high priority, can't I >force all of the machines on a network to swing >back and forth between two DISs?) > I don't remember of the top of my head whether ISIS spec prescribes that but many good implementations tend to artificially bump their DIS priority significantly when elected to prevent other routers with same or just slightly higher priority to bump them of the DIS. This stops a problem if e.g. a router with highest ID on a LAN with everyone being same priority is flacky. This has a good chance to prevent this kind of attack as well. Loosing DIS is unplesant for everyone, that's why e.g. OSPF went the whole nine-yards to get the BDR working. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 03:44:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26753 for ; Fri, 26 Apr 2002 03:44:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q7SSt32438; Fri, 26 Apr 2002 00:28:28 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3Q7KKt32382 for ; Fri, 26 Apr 2002 00:20:20 -0700 (PDT) (envelope-from prz@redback.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3Q7Xrn20784 for ; Fri, 26 Apr 2002 00:33:53 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 25 Apr 2002 23:31:51 -0700 Received: from redback.com ([63.200.51.103]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV5006LDWWERM@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 25 Apr 2002 23:33:51 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] About MTU? To: selvarajr@future.futsoft.com Cc: "'Ravindra Sunkad'" , "'Jeff Learman'" , "'Wang xuepu'" , isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CC8E367.169B1CBE@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <001001c1ece6$b598ae80$2006040a@future.futsoft.com> X-OriginalArrivalTime: 26 Apr 2002 06:31:51.0421 (UTC) FILETIME=[0CCBE2D0:01C1ECEC] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Apr 2002 22:19:35 -0700 Content-Transfer-Encoding: 7BIT SelvarajR wrote: > Hi, > I guess the latest 10589v2 address this by defining new TLV. > But apologies in advance that I'm not well sure about that. > The idea is that all the ISIS process in the domain agreeing upon for the > least MTU in the domain. All ISIS process should advertise their least > interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then, > each ISIS process shall scan there LSP data base and select the least MTU > among those advertised in the LSP, including its own LSP. This least MTU > shall be used as the LSPBufferSize. If there is any change in the current > LSPBufferSize then the ISIS process shall restart. > > For this all the ISIS process should support the new TLV. > This mechanism may have quite few number of ISIS process restart as an > overhead. > No Pain No Gain ;) > I guess this may solve the problem. yes, there is a proposal hanging, other people are better informed than me. It was forwarded to this list or it's on my or maybe jeff's plate to get it forwarded to this list via a liason if I'm not mistaken. I better go and check my to-do list ;-) - -tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 10:28:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05706 for ; Fri, 26 Apr 2002 10:28:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3QEC1t34698; Fri, 26 Apr 2002 07:12:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3QEB4t34686 for ; Fri, 26 Apr 2002 07:11:04 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Tony Przygienda'" , "Les Ginsberg (E-mail)" Cc: "'RJ Atkinson'" , "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] *SNP replay MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Apr 2002 10:23:24 -0400 > >(The only other packet I can think of with leverage > >is changing the priority on a hello to force a > >DIS election. If I send a duplicate of a hello > >from a low-status IS with high priority, can't I > >force all of the machines on a network to swing > >back and forth between two DISs?) > > > I don't remember of the top of my head whether ISIS spec > prescribes that but many good implementations tend to > artificially bump their DIS priority significantly when > elected.... .... > OSPF went the whole nine-yards to get the BDR working. > > -- tony Even if you promote yourself when you become DIS, if someone has a copy of a valid old packet in which you had low priority, they can send that, alternating the old with your new copy, and create churn until the key rolls over. It was interesting that Les's suggestion yesterday included just such a low-priority packet when a router reboots. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 26 11:11:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07216 for ; Fri, 26 Apr 2002 11:11:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3QEuit34924; Fri, 26 Apr 2002 07:56:44 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3QEp0t34895 for ; Fri, 26 Apr 2002 07:51:00 -0700 (PDT) (envelope-from jparker@axiowave.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3QF4Z614454 for ; Fri, 26 Apr 2002 08:04:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Fri, 26 Apr 2002 07:26:21 -0700 Message-ID: From: Jeff Parker To: "'prz@redback.com'" , selvarajr@future.futsoft.com Cc: "'Ravindra Sunkad'" , "'Jeff Learman'" , "'Wang xuepu'" , isis-wg@juniper.net, "Les Ginsberg (E-mail)" Subject: RE: [Isis-wg] About MTU? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Apr 2002 14:26:22.0031 (UTC) FILETIME=[569A35F0:01C1ED2E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Apr 2002 10:27:33 -0400 > It was forwarded to this list or it's on my or maybe > jeff's plate to get it forwarded to this list via a > liason if I'm not mistaken. I better go and check my > to-do list ;-) > > - -tony Right. This is on the "update list"'s plate. I should have replied earlier. Here is the text I have at present: the major work is Les' while the errors are mine. - jdp 8.0 ReceiveLSPBufferSize Since IS-IS does not allow segmentation of protocol PDUs, Link State PDUs (LSPs) must be propagated without modification on all IS-IS enabled links throughout the area/domain. Thus it is essential to configure a maximum size that all routers can forward, receive, and store. This affects three aspects, which we discuss in turn: (1) The largest LSP we can receive (ReceiveLSPBufferSize) (2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize) (3) Available Link MTU for supported Circuits (MTU). Note this may differ from the MTU available to IP clients. The protocol provides the architectural constant ReceiveLSPBufferSize with value 1492 bytes, and two private management parameters, originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer Size parameters define the maximum size of an LSP that a router can generate. The protocol directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error. It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU The original thought was that operators could decrease the originat- ing Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492. With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP data- base which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492. Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible. The steps below are recommended when changing ReceiveLSPBufferSize. (1) Set the ReceiveLSPBufferSize to a consistent value throughout the network. (2) The implementation should not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level. (3) Include a originatingLSPBufferSize TLV when generating LSPs, as described in section 9.8 of [3]. (4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifica- tions and Alarms. (5) Report the receipt of a PDU larger than the local ReceiveL- SPBufferSize through the defined Notifications and Alarms. (6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misscon- figured network. Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems. > SelvarajR wrote: > > > Hi, > > I guess the latest 10589v2 address this by defining new TLV. > > But apologies in advance that I'm not well sure about that. > > The idea is that all the ISIS process in the domain > agreeing upon for the > > least MTU in the domain. All ISIS process should advertise > their least > > interface MTU(among on which ISIS is enabled, ofcourse) in > their LSPs. Then, > > each ISIS process shall scan there LSP data base and select > the least MTU > > among those advertised in the LSP, including its own LSP. > This least MTU > > shall be used as the LSPBufferSize. If there is any change > in the current > > LSPBufferSize then the ISIS process shall restart. > > > > For this all the ISIS process should support the new TLV. > > This mechanism may have quite few number of ISIS process > restart as an > > overhead. > > No Pain No Gain ;) > > I guess this may solve the problem. > > yes, there is a proposal hanging, other people are better > informed than > me. It was forwarded to this list or it's on my or maybe > jeff's plate to > get it forwarded to this list via a liason if I'm not mistaken. > I better go and check my to-do list ;-) > > - -tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 27 05:20:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09512 for ; Sat, 27 Apr 2002 05:20:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3R931t39388; Sat, 27 Apr 2002 02:03:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3R92Yt39376 for ; Sat, 27 Apr 2002 02:02:34 -0700 (PDT) (envelope-from dasnabendu@yahoo.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g3R9GDn48581 for ; Sat, 27 Apr 2002 02:16:13 -0700 (PDT) X-JNPR-Received-From: outside Received: from web13208.mail.yahoo.com ([216.136.174.193]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sat, 27 Apr 2002 01:06:26 -0700 Message-ID: <20020427080827.24516.qmail@web13208.mail.yahoo.com> Received: from [203.200.20.226] by web13208.mail.yahoo.com via HTTP; Sat, 27 Apr 2002 01:08:27 PDT From: nabendu das To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 27 Apr 2002 08:06:26.0500 (UTC) FILETIME=[6DD1F840:01C1EDC2] Subject: [Isis-wg] Integrated IS-IS in distributed architecture Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 27 Apr 2002 01:08:27 -0700 (PDT) hi all, I have few concerns regarding running IS-IS in distributed architecture. In case of distributed architecture, generally we have several routing engines within a router, where each of the routing engine act as an independent router internally. So we need to run IS-IS internally among the routing engines to make control information consistent among the routing engines. We can make some changes to run it or can add up new PDU type that will be propagated only internally. But as each of the routing engines are generating there own LSPs then how can we synchronise the sequence no.s among the routing engines because to the outside world, the router should appear as a single entity. It should appear as a single router only. So the sequnce nos also should be kept synchronized because each routing engines can not put there own MAC address in the LSPID, as in that case all the routing engines will be treated as independent router. this can be handled by putting the same MAC address for all the LSPs generated by all the routing engines. but then what about Sequence no. this also should be synchronized. PLz help in this regard. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Apr 27 16:46:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21941 for ; Sat, 27 Apr 2002 16:46:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3RKT5t45215; Sat, 27 Apr 2002 13:29:05 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3RKNYt45183 for ; Sat, 27 Apr 2002 13:23:34 -0700 (PDT) (envelope-from prz@net4u.ch) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3RKbG637599 for ; Sat, 27 Apr 2002 13:37:16 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sat, 27 Apr 2002 13:30:36 -0700 Received: from net4u.ch ([63.200.51.32]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV800L0EUEDUO@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Sat, 27 Apr 2002 13:32:37 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture To: nabendu das Cc: isis-wg@juniper.net Message-id: <3CCB13A4.4020601@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <20020427080827.24516.qmail@web13208.mail.yahoo.com> X-OriginalArrivalTime: 27 Apr 2002 20:30:36.0453 (UTC) FILETIME=[63441D50:01C1EE2A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 27 Apr 2002 14:09:56 -0700 Content-Transfer-Encoding: 7BIT nabendu das wrote: >hi all, > I have few concerns regarding running IS-IS in >distributed architecture. > In case of distributed architecture, generally >we have several routing engines within a router, where >each of the routing engine act as an independent >router internally. So we need to run IS-IS internally >among the routing engines to make control information >consistent among the routing engines. We can make some >changes to run it or can add up new PDU type that will >be propagated only internally. But as each of the >routing engines are generating there own LSPs then how >can we synchronise the sequence no.s among the routing >engines because to the outside world, the router >should appear as a single entity. It should appear as >a single router only. So the sequnce nos also should >be kept synchronized because each routing engines can >not put there own MAC address in the LSPID, as in that >case all the routing engines will be treated as >independent router. this can be handled by putting the >same MAC address for all the LSPs generated by all the >routing engines. but then what about Sequence no. this >also should be synchronized. > Nabendu, First, this list is not the right forum to discuss this topic, we should be concerned here with the interoperability aspects _between_ systems and not internal implementation details like this one. Second, you have or make a lot of assumptions of what your system looks internally like. Many people solve the problem differently and their architectures vary widely from yours. A distributed system is a vague concept in terms of routing protocols and many people choose to replicate or partition the functionality of the protocol very differently from what you suggest. I can recommend some of the modern books on distributed operating systems or databases to give you food for thoughts. And, looks like your company (and I don't assume yahoo has this problem ;-) may be in some need of a good system architect ;-) -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Apr 28 11:31:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24881 for ; Sun, 28 Apr 2002 11:31:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3SFD1t50316; Sun, 28 Apr 2002 08:13:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bart.cwnt.com (mail.cwnt.com [192.116.246.129]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3SFCHt50304 for ; Sun, 28 Apr 2002 08:12:20 -0700 (PDT) (envelope-from amir@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Message-ID: Thread-Topic: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Thread-Index: AcHsL6SAESx2F6ylTfSTzYEiPCSV1QClkhcw From: "Amir Hermelin" To: "Manral, Vishwas" Cc: , "Amir Hermelin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g3SFCit50305 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 28 Apr 2002 18:25:53 +0300 Content-Transfer-Encoding: 8bit Manral, Let me relate to some points mentioned in this dialogue. * WRT extended capabilities TLV: this new TLV was included in draft-hermelin-ext-lsp-frags-02.txt, but was removed in subsequent versions due to lack of need. I can re-add it to the draft, or maybe a separate draft would be better. Lets have opinions from the group. * We have previously considered your option of using same sys-id and frag-num, add new tlv in body. I withdrew from that mainly due to the numerous problems it introduces, most of which have been pointed out by Mike. I guess for the sake of brevity he didn't outline all of them - but it does change the update process, to my knowledge significantly. If you've mentioned code-changes, I believe your method would impose significant code changes in multiple processes. * You've referred to the two modes in the draft - note that they are completely independent. Furthermore, mode 1 imposes no changes whatsoever to the spf process, and is completely compatible with older routers. * WRT transitioning: note section 7 of the draft, first paragraph: "it is possible to not upgrade every router in the network, if the extended information is not routing information, but rather data that is of use to only a subset of routers (e.g. optical switches using ISIS could carry optical-specific information in extended LSPs)" This isn't possible with the other method. * Again note section 7. It lists a very easy (and safe) method of transitioning the network. * WRT partition repair and att bit: this is only a suggestion, and doesn't have any serious consequences whether you follow it or not. * And finally, WRT SPF changes: Mode 2 of the draft doesn't pose any real changes to SPF, only to way LSPs are "grouped". In that regard, this is exactly the same as in your proposition. I very much welcome your comments (especially since they livened up the discussion :-). -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@netplane.com] > Sent: Thursday, April 25, 2002 10:30 AM > To: 'mike shand' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > Maybe we could get someone elses views too, of what they > feel. That would > help. ;-) > > The idea of extended option in IIH is good, and may be nice for the > exp_lsp_fragment draft too(and same with domain wide etc too). > > Thanks again, > Vishwas > > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Thursday, April 25, 2002 12:47 PM > To: Manral, Vishwas > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > At 02:46 25/04/2002 -0400, Manral, Vishwas wrote: > >Hi Mike, > > > >I actually thought over it, and simplified things a bit > further, so that we > >never have to send both entry TLV's at one time. > > > >1. All routers use small LSP numbers at init time. > >2. As routers with new functionality come up, they need to > send the same > >value in header and TLV LSP numbers. They need to be ready > to accept the > >"extended LSP entry TLV. We however still send the old LSP entry TLV. > >3. Once all routers have the capability, we start using > different values in > >LSP number in the header and the TLV(extended LSP number) > and use only > >extended LSP entry TLV. > > I think you need a multi stage migration process. > > 1. Deploy new software everywhere which understands the new > TLVs, and sends > the same LSP number in both the LSP header and the extended > TLV, but still > only sends the old LSP entry TLV. > > 2. Once you have all routers with the new software, you can > go to each > router in turn and tell it to use new LSP entries instead of old. > > 3. Once you have all routers doing this, you can start using > extended LSP > numbers (i.e. different values in the TLV and the header). > > It would probably be wise to include some capability bits in > the IIHs to > prevent forming adjacencies with old routers once you have > started using > extended LSP numbers. > > > But, note that this is a complex process and requires changes > to all the > update process code AND the SPF process code to recognize the > additional > LSP numbers, AND the hello processing code (if we want to make it > reasonably safe). > > I'd MUCH rather confine the changes to the SPF. > > Mike > > > >Does this sound ok? ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Wednesday, April 24, 2002 7:55 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: > > >Hi folks, > > > > > >As I have not got the reply to my mail, I will try and > restate(I guess I > > >wasn't clear) what the proposal is. > > > > > >The idea is to have a new TLV called LSP Number TLV, which > contains a 32 > >bit > > >LSP number. The new TLV is propagated in all LSP's and > overrides the LSP > > >Number field in the header. > > > > > >To migrate to this scheme, as long as all the routers in > the network do > not > > >support the new TLV, we use the same value in LSP number > field in the > >header > > >as well as the TLV. Once all the routers in the network > support the new > >TLV, > > >we can actually use the value of the LSP number TLV and > ignore the LSP > > >number field in the header. > > > > > >The solution in this scheme seems to be a logical > extension to the limit > > >caused by an 8 bit LSP number field, using a 32 bit > sequence number, > rather > > >than the scheme where we need multiple system id's and > then equating the > > >ID's. > > > > > >The advantages of the scheme relative to the other scheme is: - > > > > > >a) We use a simple migration scheme rather than a two step > highly complex > > >scheme. > > >b) We need not worry about any change to routing table > calculations. > > >c) No taking care of attached bit. > > >d) No taking care of partition bit. > > >e) We need not worry about which links use what system > id(as in the other > > >scheme) and hence a lot of configuration. > > >f) The amount of code changes are minimal. > > > > > >Regarding Mike's comment(I hope I got it right, Mike?) > what happens when > a > > >new router that does not support the functionality comes > up. Although the > > >assumption with the other drafts like domain-wide and wide > metrics is > that > > >once we migrate to a scheme, we will not try and bother > about the older > > >scheme, the same problem would occur in the other draft > too if a new > router > > >came up after we had migrated to method 2, and someone did > not understand > > >the ISIS Alias TLV described there. Routing loops could > very easily occur > > >there. > > > >Where do you put the extended numbers in xSNPs? Or are you > proposing a new > >"extended" LSP entry TLV? What do you do for migration? send both? > > > >Even if you do this, if you have a router which doesn't > understand the new > >stuff and you are using the extended number space, you will > get perpetual > >re-transmission if you have two LSPs with the same "natural" > number but > >different extended numbers sent to a non-participating > router. It will only > >ACK one of them. et.c etc. > > > > Mike > > > > > > >Any comments/criticism invited. > > > > > >Thanks a lot, > > >Vishwas > > > > > >-----Original Message----- > > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > > >Sent: Tuesday, April 23, 2002 8:51 PM > > >To: 'mike shand' > > >Cc: 'isis-wg@spider.juniper.net' > > >Subject: RE: [Isis-wg] Regarding > draft-ietf-isis-ext-lsp-frags-00.txt > > > > > > > > >Hi Mike, > > > > > >Thanks for the reply. > > > > > >I do not understand if we have migrated to a bigger LSp > number, why we > >would > > >bring in a router that still uses a smaller LSP number, > even when we know > >it > > >could create problems. This problem can occur in all cases > of migration > > >a) to domain wide > > >b) wide metrics > > > > > >I do not see why we should introduce a two pronged method > to do something > > >which we can do pretty easily with just a TLV change, when similar > > >approaches have been taken for other cases. Even in domain > wide if a > router > > >came in which did not use external reachability in cases > of L1 area the > >same > > >problem would occur. I do not find the reason convincing > enough to be > > >rejected. ;-) > > > > > >Thanks, > > >Vishwas > > > > > >-----Original Message----- > > >From: mike shand [mailto:mshand@cisco.com] > > >Sent: Tuesday, April 23, 2002 6:13 PM > > >To: Manral, Vishwas > > >Cc: 'isis-wg@spider.juniper.net' > > >Subject: Re: [Isis-wg] Regarding > draft-ietf-isis-ext-lsp-frags-00.txt > > > > > > > > >I'm not sure I fully understand this proposal. I assume > that when you > > >actually start using extended numbers you still need to > invent additional > > >system ID's for the extra "fragments" so that the update > process can > > >distinguish them. In which case it is semantically identical to the > current > > >scheme. > > > > > >Or are you proposing changing the update process so that > it looks at the > > >new TLV? I guess that must be what you have in mind. This > has fairly > > >serious consequences if you have migrated to extended > numbers, but you > then > > >introduce a router which doesn't understand the new update > process. I > > >thought we had already considered and rejected solutions > of this type. > > > > > > Mike > > > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > > >Hi Amir/Stefano/Mike, > > > > > > > >I read thru ur draft and had an alternate idea in mind. > I wanted to > know > > > >what you thought of it. > > > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) > quantity in TLV: - > > > > > > > >The idea is to have a new TLV, which tells the actual > LSP number. The > LSP > > > >number in the psudonode-id is not used. The changes required are > minimum. > > >We > > > >anyway scan thru TLV's for authentication information, > we can find the > >LSP > > > >number TLV then. We instead use this TLV. > > > > > > > >To migrate to such a method all we need to do is to, use same LSP > numbers > > >in > > > >the header and the TLV, and once all routers recognize > the TLV, we > >actually > > > >can use different numbers. This does not create any backward > >compatibility > > > >issues and so we dont need two methods. In this case we > do not need to > > >worry > > > >about Attached bit, Partition repair bit or change to > SPF calculations > >etc. > > > >The solution also seems a logical extension, to the > constraint caused > by > >8 > > > >bit LSP number value. Rather than a solution that has > multiple system > >id's > > > >which is like fooling the IS to believe all the systems > are the same. > > > > > > > >Thanks, > > > >Vishwas > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Apr 28 21:33:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21646 for ; Sun, 28 Apr 2002 21:33:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3T1I2t52755; Sun, 28 Apr 2002 18:18:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3T1Hdt52743 for ; Sun, 28 Apr 2002 18:17:39 -0700 (PDT) (envelope-from ruwhite@cisco.com) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA22806; Sun, 28 Apr 2002 21:31:26 -0400 (EDT) From: Russ White Reply-To: Russ White To: Naiming Shen cc: mike shand , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft In-Reply-To: <20020426062545.B3FB11DCC6C@prattle.redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 28 Apr 2002 21:31:26 -0400 (EDT) Then perhaps we should recommend them for p2p links. > retries, at least the mechanism in the current draft, only > solves some easy cases, such as the re-start IIHs get lost on > p2p links. Let's see what can happen on a LAN: assume we have > routers A, B, C and D on the LAN. A is the re-start router. A > sends out a re-start IIH on the LAN, only C and D get it. > There is a way for A to know B is on the LAN by looking the > re-start ACKs sent back by C and D(assume they didn't get > lost). B should be listed as one of the neighbors of C and D. > should we retry? -- In the case where you are the dis, then you need to send the retries to all of the is' on the network. In that case, any which receive two would just ignore the subsequent ones. -- In the case where you're not the dis, you're primary concern is the dis (obviously your dropping out isn't going to effect who the dis is if you're not currently the dis), so retries should directed at the dis, I would think. The rest of the adj's can be straightened out as needed. Does this help your broadcast network case any? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 29 04:57:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13852 for ; Mon, 29 Apr 2002 04:57:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3T8f2t54609; Mon, 29 Apr 2002 01:41:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3T8eSt54597 for ; Mon, 29 Apr 2002 01:40:28 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3T8sKX53406 for ; Mon, 29 Apr 2002 01:54:20 -0700 (PDT) X-JNPR-Received-From: outside Received: from cisco.com ([144.254.98.48]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 29 Apr 2002 01:52:17 -0700 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp193.cisco.com [10.50.0.192]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA28014; Mon, 29 Apr 2002 09:53:58 +0100 (BST) Message-Id: <4.3.2.7.2.20020429094715.04125dd0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: mike shand Subject: RE: [Isis-wg] About MTU? Cc: , "'Ravindra Sunkad'" , "'Jeff Learman'" , "'Wang xuepu'" , In-Reply-To: <001001c1ece6$b598ae80$2006040a@future.futsoft.com> References: <3CC8A7E9.E759A617@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Apr 2002 08:52:17.0249 (UTC) FILETIME=[2A387510:01C1EF5B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Apr 2002 09:53:06 +0100 At 11:23 26/04/2002 +0530, SelvarajR wrote: >Hi, >I guess the latest 10589v2 address this by defining new TLV. >But apologies in advance that I'm not well sure about that. >The idea is that all the ISIS process in the domain agreeing upon for the >least MTU in the domain. All ISIS process should advertise their least >interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then, >each ISIS process shall scan there LSP data base and select the least MTU >among those advertised in the LSP, including its own LSP. This least MTU >shall be used as the LSPBufferSize. If there is any change in the current >LSPBufferSize then the ISIS process shall restart. The problem with "solutions" of this type, (everyone advertises their requirements and we select the best one dynamically) is that they are very sensitive to problems caused by introduction of new routers (deliberately or accidentally), partitioning (so that some demanding router is not seen for a while) and then recovery (so that it pops back up again), and area merging etc. etc. Nice though "automatic" configuration may be, I can't help feeling that only the network designer/operator really knows what is required, and attempts by the protocol to second guess this on the fly, on the basis of incomplete information, are ultimately doomed to failure. Not that I'm a pessimist or anything :-) Mike ps. WARNING about potential misconfiguration is one thing. "Correcting" it is another. >For this all the ISIS process should support the new TLV. >This mechanism may have quite few number of ISIS process restart as an >overhead. >No Pain No Gain ;) >I guess this may solve the problem. > >Selva. > >| -----Original Message----- >| From: isis-wg-admin@spider.juniper.net >| [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Tony Przygienda >| Sent: Friday, 26 April 2002 6:36 AM >| To: Ravindra Sunkad >| Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net >| Subject: Re: [Isis-wg] About MTU? >| >| >| Ravindra Sunkad wrote: >| >| > If an implementation brings down IS-IS on interfaces with >| MTU < LSP_BUF_SIZE this problem >| > will not arise. >| > >| > >| > not good enough, the problem is transitive, you may have >| interface with MTU 4096, >| > your LSP_BUF_SIZE is 1024 >| > and you receive from your neighbor an LSP with size 2048 >| since his LSP_BUF_SIZE is set to 2048 >| > >| > -- tony >| >| _______________________________________________ >| Isis-wg mailing list - Isis-wg@spider.juniper.net >| http://spider.juniper.net/mailman/listinfo/isis-wg >| > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 29 20:36:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24358 for ; Mon, 29 Apr 2002 20:36:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3U0I2t59240; Mon, 29 Apr 2002 17:18:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3U0Hmt59228 for ; Mon, 29 Apr 2002 17:17:49 -0700 (PDT) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g3U0ViX74865 for ; Mon, 29 Apr 2002 17:31:45 -0700 (PDT) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 29 Apr 2002 17:29:41 -0700 Received: from miata.procket.com (unknown [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 0589823C36; Mon, 29 Apr 2002 17:20:11 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g3U0VivM012309; Mon, 29 Apr 2002 17:31:44 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g3U0VhW4010012; Mon, 29 Apr 2002 17:31:43 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15565.58863.825353.642170@alpha-tli.procket.com> To: nabendu das Cc: isis-wg@juniper.net Subject: [Isis-wg] Integrated IS-IS in distributed architecture In-Reply-To: <20020427080827.24516.qmail@web13208.mail.yahoo.com> References: <20020427080827.24516.qmail@web13208.mail.yahoo.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 30 Apr 2002 00:29:41.0359 (UTC) FILETIME=[1E528FF0:01C1EFDE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Apr 2002 17:31:43 -0700 Content-Transfer-Encoding: 7bit Whatever you decide to do, the rest of the world shouldn't ever know about it. ;-) Tony nabendu das writes: | hi all, | I have few concerns regarding running IS-IS in | distributed architecture. | In case of distributed architecture, generally | we have several routing engines within a router, where | each of the routing engine act as an independent | router internally. So we need to run IS-IS internally | among the routing engines to make control information | consistent among the routing engines. We can make some | changes to run it or can add up new PDU type that will | be propagated only internally. But as each of the | routing engines are generating there own LSPs then how | can we synchronise the sequence no.s among the routing | engines because to the outside world, the router | should appear as a single entity. It should appear as | a single router only. So the sequnce nos also should | be kept synchronized because each routing engines can | not put there own MAC address in the LSPID, as in that | case all the routing engines will be treated as | independent router. this can be handled by putting the | same MAC address for all the LSPs generated by all the | routing engines. but then what about Sequence no. this | also should be synchronized. | | PLz help in this regard. | | __________________________________________________ | Do You Yahoo!? | Yahoo! Health - your guide to health and wellness | http://health.yahoo.com | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 30 16:35:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08112 for ; Tue, 30 Apr 2002 16:35:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UKH2t64743; Tue, 30 Apr 2002 13:17:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UKGQt64731 for ; Tue, 30 Apr 2002 13:16:26 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 5C4A3F2C44; Tue, 30 Apr 2002 13:30:27 -0700 (PDT) To: mike shand Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft In-reply-to: Mail from mike shand dated Wed, 24 Apr 2002 14:53:26 BST <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com> From: Naiming Shen Message-Id: <20020430203027.5C4A3F2C44@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Apr 2002 13:30:27 -0700 Mike, ] > ] > I would change "DO NOT" into "MUST" here. ] ] I think, given the various scenarios, we need a bit of flexibility here. My ] intent was that the whole thing was "fail safe". i.e. if the restarting ] router didn't come back up properly, the neighbors would drop their ] adjacencies as if it had just plain failed. I didn't want the restarting ] to delay the normal recovery. ] ] However, I understand that some implementations may not be able to get back ] up within this time, especially for short hello times, and that some ] measure of "hello I'm back, could you just give me a little extra time to ] get my act together" would be helpful. I like Nischal's suggestion here. ] Ok, if the restarting router does not come back, then it can not even send out this IIH, thats fine. There should not be any delay here. If it does send out the re-start IIH, let's trust it. Since the neighbors have no way to judge if its a good or bad re-start. My take on this is that, we either want to help this re-start neighbor or we don't want to help this neighbor. If we do decide to help, lets help it fully. And the re-starting router knows better how long it need to take for recovery. The "fail safe" measure we need is to prevent this neighbor repeatedly re-start, and that can be an implementation issue and/or a configuration issue(e.g. user can decide only allow 5 re-start helps). A router can be instructed to load new image, try three times max, if all fail, then default back to the old image. In this case, we want to make sure the 4th re-start will have enough time. ] ] > I think we should not even retry. This graceful restart is ] > not meant to be bullet proof. If the IIHs happen to get lost, ] > we just have a bad day. This is also the same problem if you ] > have multiple neighbors on the same LAN. Your IIH can be lost ] > to one of the neighbors, but as soon as you receive from ] > other neighbors and complete the CSNPs, the T1 will be cancelled. ] > But you have no way to know, that one neighbor didn't ] > receive your re-start IIH, and it will reset the adjacency. ] > The current scheme does not cover that case, and I think its ] > not worth to have retries in general. Thus actually we don't ] > even need the T1. ] ] I'm not sure. I didn't like the idea that we may be stalled waiting for ] multiple retries, but OTOH it goes against the grain to design a protocol ] which "fails" on the loss of a single packet :-) ] ] I guess the question is how many times will we sit around waiting for a ] response when we will never get one, as opposed to the times when we ] genuinely loose a packet and this allows us to re-start when we otherwise ] wouldn't. Retry is fine as long as it leaves to the implementation for the N retries, the N can also be zero. As I mentioned in another email exchange, the current retry seems only cover the p2p case, the LAN case is more complicated. If we lose IIHs, even in normal cases, we will drop adjacencies. I don't feel particularly bad when this re-start IIH get lost:-) the worst case is this adjacency is dropped during the restart, it helps reducing unnecessary flooding also:-) ] ] Any other opinions? ] ] > I would be very careful setting OL bit here. T3 times out just ] > means we are sending out normal IIHs, that should not affect ] > anything even we have not acquired all the LSPs from neighbors ] > or we haven't finished our SPF. ] > ] > The goal of this graceful restart is to do non-stop forwarding, ] > if we send out our LSPs with OL on, it's not non-stop forwarding ] > any more. Yes our SPF has not finished yet, so what's the hurry? ] > why not let it to finish? Its much better to delay sending out ] > our LSPs(assume topology has not changed during re-start) since ] > routers in the area has our old LSPs containing the same ] > information, than to send out LSPs immaturely with OL bit set. ] ] The point is that we have time that we are prepared to run headless. That ] time has expired. We may be generating all sorts of loops and confusion (or ] we may not of course - we don't know). What do we do? Continue to screw up ] the traffic, or admit defeat and take ourselves out? I suggest that the ] only honest thing to do is the latter. We COULD do this by dropping all our ] adjacencies and getting our neighbors to sends LSPs saying we had gone ] away. However it seems cleaner simply to set our overload bit. This is ] after all what we would expect to do if we were coming up without re-start ] and we we were using the OL bit in this way. ] But "That time" is defined mainly for timeout the adjacencies, its the time when we start to send out "normal" IIHs. This has a little to do with if we have finished the SPF or not. My point is that, each router has its own "time" to finish the re-start. Its affected by its position in the network, its configuration size, does it have a huge bgp download at the time(not applicable if the implementation have isis and bgp running on diff CPUs), does someone have a big image downloading or bulkstats collections at the time, etc. If for example this "time" is 25 seconds, and at re-start a particular router may need 27 seconds. Yes, there needs to be a fixed maximum time, say 5 minutes not finished, lets shut the isis down. But only the users can decide that. If the router has serious problem, i doubt it can properly send out this OL bit labelled packet, or even read time correctly. ] However, it may be undesirable to actually insist on this behaviour. Maybe ] it should say that if you are following the setting the OL bit when you ] come up stuff, now would be a good time to do it. ] ] > If the re-start router has one hundred IS-IS interfaces, at ] > restart, it will receive 100 copies of the databases from ] > all the interfaces assume all the neighbors can help. We ] > also need to flooding all of them to the other 99 interfaces ] > 100 times. ] ] Um... 100 times? Why? Yes we flood the first copy we see of each LSP to all ] the other 99, but subsequent copies are just acked. I was just saying a huge number. Yes, if they happen to occur at the same time, lots of them will cancel each other. But some of them will not. Say I get LSP X from intf a, flood this to intf b and c. At the same time I get X from b also(b sent out before it got X from me), but the SRM is cleared on intf c since I already sent X out. So I need to flood X from b to intf a and c again. True, definitely not 100 times. ] ] I'm not sure whether these sort of optimizations need to be spelled out in ] the spec. There is some considerable scope for individual implementations ] ingenuity within the basic framework here. I don't think we want to ] over-constrain. Ok, I agree no need to mention optimization in the draft. Lets leave it to implementations. thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 30 17:07:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08961 for ; Tue, 30 Apr 2002 17:07:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UKoQt64930; Tue, 30 Apr 2002 13:50:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UKdTt64857 for ; Tue, 30 Apr 2002 13:39:29 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 7526ACAB6C; Tue, 30 Apr 2002 13:53:30 -0700 (PDT) To: Russ White Cc: mike shand , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft In-reply-to: Mail from Russ White dated Sun, 28 Apr 2002 21:31:26 EDT From: Naiming Shen Message-Id: <20020430205330.7526ACAB6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Apr 2002 13:53:30 -0700 ] ] Then perhaps we should recommend them for p2p links. fine, but lan has more chance to lose pkts i would think. ] ] -- In the case where you are the dis, then you need to send the ] retries to all of the is' on the network. In that case, any which ] receive two would just ignore the subsequent ones. how do we decide if the neighbor restarted again, or is doing retries? even the re-start router is the dis, someone else on the LAN suppose to serve as a "temp" dis for help. even though we can put a re-start counter in the re-start IIH saying this is numberX retry, still how do we know it's due to someone else on the LAN didn't send ACK, or my ACK actually got lost? ] ] -- In the case where you're not the dis, you're primary concern ] is the dis (obviously your dropping out isn't going to effect who ] the dis is if you're not currently the dis), so retries should ] directed at the dis, I would think. The rest of the adj's can be ] straightened out as needed. ] ] Does this help your broadcast network case any? ] I think the simplist way is NOT to retry. Simply just sit and wait. Your neighbor WILL send you a "normal" IIH, since it does not know you just restarted. Just treat this "normal" IIH as it sends back the ACK. Ok, what if this neighbor is the DIS or "temp" DIS, we don't get all the lsps from it? but over other interfaces, we may get more than enough of them. Ok, what if we only have one interface? then adjacency reset or not does not affect traffic flow, since there is only one way to go; Ok, what if all the interface we lose all the re-start IIHs? then we probably should not being graceful anymore:-) - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 30 19:04:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11962 for ; Tue, 30 Apr 2002 19:04:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UMlpt65505; Tue, 30 Apr 2002 15:47:51 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from viva1.vivacenetworks.com ([64.221.212.135]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3UMVbt65427 for ; Tue, 30 Apr 2002 15:31:37 -0700 (PDT) (envelope-from Hema.Malik@vivacenetworks.com) Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 15:44:40 -0700 Message-ID: From: Hema Malik To: "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] help Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Apr 2002 15:44:39 -0700 I want to unsubscribe to the mailing list. -----Original Message----- From: isis-wg-request@external.juniper.net [mailto:isis-wg-request@external.juniper.net] Sent: Sunday, April 28, 2002 6:23 PM To: isis-wg@spider.juniper.net Subject: Isis-wg digest, Vol 1 #235 - 7 msgs Send Isis-wg mailing list submissions to isis-wg@spider.juniper.net To subscribe or unsubscribe via the World Wide Web, visit http://spider.juniper.net/mailman/listinfo/isis-wg or, via email, send a message with subject or body 'help' to isis-wg-request@spider.juniper.net You can reach the person managing the list at isis-wg-admin@spider.juniper.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Isis-wg digest..." Today's Topics: 1. Re: About MTU? (Tony Przygienda) 2. RE: *SNP replay (Jeff Parker) 3. RE: About MTU? (Jeff Parker) 4. Integrated IS-IS in distributed architecture (nabendu das) 5. Re: Integrated IS-IS in distributed architecture (Tony Przygienda) 6. RE: Regarding draft-ietf-isis-ext-lsp-frags-00.txt (Amir Hermelin) 7. Re: Re: a few comments on ietf restart isis draft (Russ White) --__--__-- Message: 1 Date: Thu, 25 Apr 2002 22:19:35 -0700 From: Tony Przygienda Subject: Re: [Isis-wg] About MTU? To: selvarajr@future.futsoft.com Cc: "'Ravindra Sunkad'" , "'Jeff Learman'" , "'Wang xuepu'" , isis-wg@juniper.net Reply-to: prz@redback.com SelvarajR wrote: > Hi, > I guess the latest 10589v2 address this by defining new TLV. But > apologies in advance that I'm not well sure about that. The idea is > that all the ISIS process in the domain agreeing upon for the least > MTU in the domain. All ISIS process should advertise their least > interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. > Then, each ISIS process shall scan there LSP data base and select the > least MTU among those advertised in the LSP, including its own LSP. > This least MTU shall be used as the LSPBufferSize. If there is any > change in the current LSPBufferSize then the ISIS process shall > restart. > > For this all the ISIS process should support the new TLV. This > mechanism may have quite few number of ISIS process restart as an > overhead. No Pain No Gain ;) > I guess this may solve the problem. yes, there is a proposal hanging, other people are better informed than me. It was forwarded to this list or it's on my or maybe jeff's plate to get it forwarded to this list via a liason if I'm not mistaken. I better go and check my to-do list ;-) - -tony --__--__-- Message: 2 From: Jeff Parker To: "'Tony Przygienda'" , "Les Ginsberg (E-mail)" Cc: "'RJ Atkinson'" , "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] *SNP replay Date: Fri, 26 Apr 2002 10:23:24 -0400 > >(The only other packet I can think of with leverage > >is changing the priority on a hello to force a > >DIS election. If I send a duplicate of a hello > >from a low-status IS with high priority, can't I > >force all of the machines on a network to swing > >back and forth between two DISs?) > > > I don't remember of the top of my head whether ISIS spec > prescribes that but many good implementations tend to > artificially bump their DIS priority significantly when > elected.... .... > OSPF went the whole nine-yards to get the BDR working. > > -- tony Even if you promote yourself when you become DIS, if someone has a copy of a valid old packet in which you had low priority, they can send that, alternating the old with your new copy, and create churn until the key rolls over. It was interesting that Les's suggestion yesterday included just such a low-priority packet when a router reboots. - jeff parker --__--__-- Message: 3 From: Jeff Parker To: "'prz@redback.com'" , selvarajr@future.futsoft.com Cc: "'Ravindra Sunkad'" , "'Jeff Learman'" , "'Wang xuepu'" , isis-wg@juniper.net, "Les Ginsberg (E-mail)" Subject: RE: [Isis-wg] About MTU? Date: Fri, 26 Apr 2002 10:27:33 -0400 > It was forwarded to this list or it's on my or maybe > jeff's plate to get it forwarded to this list via a > liason if I'm not mistaken. I better go and check my > to-do list ;-) > > - -tony Right. This is on the "update list"'s plate. I should have replied earlier. Here is the text I have at present: the major work is Les' while the errors are mine. - jdp 8.0 ReceiveLSPBufferSize Since IS-IS does not allow segmentation of protocol PDUs, Link State PDUs (LSPs) must be propagated without modification on all IS-IS enabled links throughout the area/domain. Thus it is essential to configure a maximum size that all routers can forward, receive, and store. This affects three aspects, which we discuss in turn: (1) The largest LSP we can receive (ReceiveLSPBufferSize) (2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize) (3) Available Link MTU for supported Circuits (MTU). Note this may differ from the MTU available to IP clients. The protocol provides the architectural constant ReceiveLSPBufferSize with value 1492 bytes, and two private management parameters, originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer Size parameters define the maximum size of an LSP that a router can generate. The protocol directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error. It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU The original thought was that operators could decrease the originat- ing Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492. With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP data- base which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492. Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible. The steps below are recommended when changing ReceiveLSPBufferSize. (1) Set the ReceiveLSPBufferSize to a consistent value throughout the network. (2) The implementation should not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level. (3) Include a originatingLSPBufferSize TLV when generating LSPs, as described in section 9.8 of [3]. (4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifica- tions and Alarms. (5) Report the receipt of a PDU larger than the local ReceiveL- SPBufferSize through the defined Notifications and Alarms. (6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misscon- figured network. Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems. > SelvarajR wrote: > > > Hi, > > I guess the latest 10589v2 address this by defining new TLV. But > > apologies in advance that I'm not well sure about that. The idea is > > that all the ISIS process in the domain > agreeing upon for the > > least MTU in the domain. All ISIS process should advertise > their least > > interface MTU(among on which ISIS is enabled, ofcourse) in > their LSPs. Then, > > each ISIS process shall scan there LSP data base and select > the least MTU > > among those advertised in the LSP, including its own LSP. > This least MTU > > shall be used as the LSPBufferSize. If there is any change > in the current > > LSPBufferSize then the ISIS process shall restart. > > > > For this all the ISIS process should support the new TLV. This > > mechanism may have quite few number of ISIS process > restart as an > > overhead. > > No Pain No Gain ;) > > I guess this may solve the problem. > > yes, there is a proposal hanging, other people are better > informed than > me. It was forwarded to this list or it's on my or maybe > jeff's plate to > get it forwarded to this list via a liason if I'm not mistaken. > I better go and check my to-do list ;-) > > - -tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > --__--__-- Message: 4 Date: Sat, 27 Apr 2002 01:08:27 -0700 (PDT) From: nabendu das To: isis-wg@juniper.net Subject: [Isis-wg] Integrated IS-IS in distributed architecture hi all, I have few concerns regarding running IS-IS in distributed architecture. In case of distributed architecture, generally we have several routing engines within a router, where each of the routing engine act as an independent router internally. So we need to run IS-IS internally among the routing engines to make control information consistent among the routing engines. We can make some changes to run it or can add up new PDU type that will be propagated only internally. But as each of the routing engines are generating there own LSPs then how can we synchronise the sequence no.s among the routing engines because to the outside world, the router should appear as a single entity. It should appear as a single router only. So the sequnce nos also should be kept synchronized because each routing engines can not put there own MAC address in the LSPID, as in that case all the routing engines will be treated as independent router. this can be handled by putting the same MAC address for all the LSPs generated by all the routing engines. but then what about Sequence no. this also should be synchronized. PLz help in this regard. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com --__--__-- Message: 5 Date: Sat, 27 Apr 2002 14:09:56 -0700 From: Tony Przygienda Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture To: nabendu das Cc: isis-wg@juniper.net nabendu das wrote: >hi all, > I have few concerns regarding running IS-IS in distributed >architecture. > In case of distributed architecture, generally >we have several routing engines within a router, where >each of the routing engine act as an independent >router internally. So we need to run IS-IS internally >among the routing engines to make control information consistent among >the routing engines. We can make some changes to run it or can add up >new PDU type that will be propagated only internally. But as each of >the routing engines are generating there own LSPs then how >can we synchronise the sequence no.s among the routing >engines because to the outside world, the router >should appear as a single entity. It should appear as >a single router only. So the sequnce nos also should >be kept synchronized because each routing engines can >not put there own MAC address in the LSPID, as in that >case all the routing engines will be treated as >independent router. this can be handled by putting the >same MAC address for all the LSPs generated by all the >routing engines. but then what about Sequence no. this >also should be synchronized. > Nabendu, First, this list is not the right forum to discuss this topic, we should be concerned here with the interoperability aspects _between_ systems and not internal implementation details like this one. Second, you have or make a lot of assumptions of what your system looks internally like. Many people solve the problem differently and their architectures vary widely from yours. A distributed system is a vague concept in terms of routing protocols and many people choose to replicate or partition the functionality of the protocol very differently from what you suggest. I can recommend some of the modern books on distributed operating systems or databases to give you food for thoughts. And, looks like your company (and I don't assume yahoo has this problem ;-) may be in some need of a good system architect ;-) -- tony --__--__-- Message: 6 Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt Date: Sun, 28 Apr 2002 18:25:53 +0300 From: "Amir Hermelin" To: "Manral, Vishwas" Cc: , "Amir Hermelin" Manral, Let me relate to some points mentioned in this dialogue. * WRT extended capabilities TLV: this new TLV was included in draft-hermelin-ext-lsp-frags-02.txt, but was removed in subsequent versions due to lack of need. I can re-add it to the draft, or maybe a separate draft would be better. Lets have opinions from the group. * We have previously considered your option of using same sys-id and frag-num, add new tlv in body. I withdrew from that mainly due to the numerous problems it introduces, most of which have been pointed out by Mike. I guess for the sake of brevity he didn't outline all of them - but it does change the update process, to my knowledge significantly. If you've mentioned code-changes, I believe your method would impose significant code changes in multiple processes. * You've referred to the two modes in the draft - note that they are completely independent. Furthermore, mode 1 imposes no changes whatsoever to the spf process, and is completely compatible with older routers. * WRT transitioning: note section 7 of the draft, first paragraph: "it is possible to not upgrade every router in the network, if the extended information is not routing information, but rather data that is of use to only a subset of routers (e.g. optical switches using ISIS could carry optical-specific information in extended LSPs)" This isn't possible with the other method. * Again note section 7. It lists a very easy (and safe) method of transitioning the network. * WRT partition repair and att bit: this is only a suggestion, and doesn't have any serious consequences whether you follow it or not. * And finally, WRT SPF changes: Mode 2 of the draft doesn't pose any real changes to SPF, only to way LSPs are "grouped". In that regard, this is exactly the same as in your proposition. I very much welcome your comments (especially since they livened up the discussion :-). -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@netplane.com] > Sent: Thursday, April 25, 2002 10:30 AM > To: 'mike shand' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > Maybe we could get someone elses views too, of what they > feel. That would > help. ;-) > > The idea of extended option in IIH is good, and may be nice for the > exp_lsp_fragment draft too(and same with domain wide etc too). > > Thanks again, > Vishwas > > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Thursday, April 25, 2002 12:47 PM > To: Manral, Vishwas > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > At 02:46 25/04/2002 -0400, Manral, Vishwas wrote: > >Hi Mike, > > > >I actually thought over it, and simplified things a bit > further, so that we > >never have to send both entry TLV's at one time. > > > >1. All routers use small LSP numbers at init time. > >2. As routers with new functionality come up, they need to > send the same > >value in header and TLV LSP numbers. They need to be ready > to accept the > >"extended LSP entry TLV. We however still send the old LSP entry TLV. > >3. Once all routers have the capability, we start using > different values in > >LSP number in the header and the TLV(extended LSP number) > and use only > >extended LSP entry TLV. > > I think you need a multi stage migration process. > > 1. Deploy new software everywhere which understands the new > TLVs, and sends > the same LSP number in both the LSP header and the extended > TLV, but still > only sends the old LSP entry TLV. > > 2. Once you have all routers with the new software, you can > go to each > router in turn and tell it to use new LSP entries instead of old. > > 3. Once you have all routers doing this, you can start using > extended LSP > numbers (i.e. different values in the TLV and the header). > > It would probably be wise to include some capability bits in > the IIHs to > prevent forming adjacencies with old routers once you have > started using > extended LSP numbers. > > > But, note that this is a complex process and requires changes > to all the > update process code AND the SPF process code to recognize the > additional > LSP numbers, AND the hello processing code (if we want to make it > reasonably safe). > > I'd MUCH rather confine the changes to the SPF. > > Mike > > > >Does this sound ok? ;-) > > > >Thanks, > >Vishwas > > > >-----Original Message----- > >From: mike shand [mailto:mshand@cisco.com] > >Sent: Wednesday, April 24, 2002 7:55 PM > >To: Manral, Vishwas > >Cc: 'isis-wg@spider.juniper.net' > >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt > > > > > >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote: > > >Hi folks, > > > > > >As I have not got the reply to my mail, I will try and > restate(I guess I > > >wasn't clear) what the proposal is. > > > > > >The idea is to have a new TLV called LSP Number TLV, which > contains a 32 > >bit > > >LSP number. The new TLV is propagated in all LSP's and > overrides the LSP > > >Number field in the header. > > > > > >To migrate to this scheme, as long as all the routers in > the network do > not > > >support the new TLV, we use the same value in LSP number > field in the > >header > > >as well as the TLV. Once all the routers in the network > support the new > >TLV, > > >we can actually use the value of the LSP number TLV and > ignore the LSP > > >number field in the header. > > > > > >The solution in this scheme seems to be a logical > extension to the limit > > >caused by an 8 bit LSP number field, using a 32 bit > sequence number, > rather > > >than the scheme where we need multiple system id's and > then equating the > > >ID's. > > > > > >The advantages of the scheme relative to the other scheme is: - > > > > > >a) We use a simple migration scheme rather than a two step > highly complex > > >scheme. > > >b) We need not worry about any change to routing table > calculations. > > >c) No taking care of attached bit. > > >d) No taking care of partition bit. > > >e) We need not worry about which links use what system > id(as in the other > > >scheme) and hence a lot of configuration. > > >f) The amount of code changes are minimal. > > > > > >Regarding Mike's comment(I hope I got it right, Mike?) > what happens when > a > > >new router that does not support the functionality comes > up. Although the > > >assumption with the other drafts like domain-wide and wide > metrics is > that > > >once we migrate to a scheme, we will not try and bother > about the older > > >scheme, the same problem would occur in the other draft > too if a new > router > > >came up after we had migrated to method 2, and someone did > not understand > > >the ISIS Alias TLV described there. Routing loops could > very easily occur > > >there. > > > >Where do you put the extended numbers in xSNPs? Or are you > proposing a new > >"extended" LSP entry TLV? What do you do for migration? send both? > > > >Even if you do this, if you have a router which doesn't > understand the new > >stuff and you are using the extended number space, you will > get perpetual > >re-transmission if you have two LSPs with the same "natural" > number but > >different extended numbers sent to a non-participating > router. It will only > >ACK one of them. et.c etc. > > > > Mike > > > > > > >Any comments/criticism invited. > > > > > >Thanks a lot, > > >Vishwas > > > > > >-----Original Message----- > > >From: Manral, Vishwas [mailto:VishwasM@netplane.com] > > >Sent: Tuesday, April 23, 2002 8:51 PM > > >To: 'mike shand' > > >Cc: 'isis-wg@spider.juniper.net' > > >Subject: RE: [Isis-wg] Regarding > draft-ietf-isis-ext-lsp-frags-00.txt > > > > > > > > >Hi Mike, > > > > > >Thanks for the reply. > > > > > >I do not understand if we have migrated to a bigger LSp > number, why we > >would > > >bring in a router that still uses a smaller LSP number, > even when we know > >it > > >could create problems. This problem can occur in all cases > of migration > > >a) to domain wide > > >b) wide metrics > > > > > >I do not see why we should introduce a two pronged method > to do something > > >which we can do pretty easily with just a TLV change, when similar > > >approaches have been taken for other cases. Even in domain > wide if a > router > > >came in which did not use external reachability in cases > of L1 area the > >same > > >problem would occur. I do not find the reason convincing > enough to be > > >rejected. ;-) > > > > > >Thanks, > > >Vishwas > > > > > >-----Original Message----- > > >From: mike shand [mailto:mshand@cisco.com] > > >Sent: Tuesday, April 23, 2002 6:13 PM > > >To: Manral, Vishwas > > >Cc: 'isis-wg@spider.juniper.net' > > >Subject: Re: [Isis-wg] Regarding > draft-ietf-isis-ext-lsp-frags-00.txt > > > > > > > > >I'm not sure I fully understand this proposal. I assume > that when you > > >actually start using extended numbers you still need to > invent additional > > >system ID's for the extra "fragments" so that the update > process can > > >distinguish them. In which case it is semantically identical to the > current > > >scheme. > > > > > >Or are you proposing changing the update process so that > it looks at the > > >new TLV? I guess that must be what you have in mind. This > has fairly > > >serious consequences if you have migrated to extended > numbers, but you > then > > >introduce a router which doesn't understand the new update > process. I > > >thought we had already considered and rejected solutions > of this type. > > > > > > Mike > > > > > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote: > > > >Hi Amir/Stefano/Mike, > > > > > > > >I read thru ur draft and had an alternate idea in mind. > I wanted to > know > > > >what you thought of it. > > > > > > > >Using the LSP number a 32 bit(or 16 bit as desired) > quantity in TLV: - > > > > > > > >The idea is to have a new TLV, which tells the actual > LSP number. The > LSP > > > >number in the psudonode-id is not used. The changes required are > minimum. > > >We > > > >anyway scan thru TLV's for authentication information, > we can find the > >LSP > > > >number TLV then. We instead use this TLV. > > > > > > > >To migrate to such a method all we need to do is to, use same LSP > numbers > > >in > > > >the header and the TLV, and once all routers recognize > the TLV, we > >actually > > > >can use different numbers. This does not create any backward > >compatibility > > > >issues and so we dont need two methods. In this case we > do not need to > > >worry > > > >about Attached bit, Partition repair bit or change to > SPF calculations > >etc. > > > >The solution also seems a logical extension, to the > constraint caused > by > >8 > > > >bit LSP number value. Rather than a solution that has > multiple system > >id's > > > >which is like fooling the IS to believe all the systems > are the same. > > > > > > > >Thanks, > > > >Vishwas > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > --__--__-- Message: 7 Date: Sun, 28 Apr 2002 21:31:26 -0400 (EDT) From: Russ White Reply-To: Russ White To: Naiming Shen cc: mike shand , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft Then perhaps we should recommend them for p2p links. > retries, at least the mechanism in the current draft, only solves some > easy cases, such as the re-start IIHs get lost on p2p links. Let's see > what can happen on a LAN: assume we have routers A, B, C and D on the > LAN. A is the re-start router. A sends out a re-start IIH on the LAN, > only C and D get it. There is a way for A to know B is on the LAN by > looking the re-start ACKs sent back by C and D(assume they didn't get > lost). B should be listed as one of the neighbors of C and D. > should we retry? -- In the case where you are the dis, then you need to send the retries to all of the is' on the network. In that case, any which receive two would just ignore the subsequent ones. -- In the case where you're not the dis, you're primary concern is the dis (obviously your dropping out isn't going to effect who the dis is if you're not currently the dis), so retries should directed at the dis, I would think. The rest of the adj's can be straightened out as needed. Does this help your broadcast network case any? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone --__--__-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg End of Isis-wg Digest _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg