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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <C99BZFVF>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>[Isis-wg] IS-IS network size</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=2>Internet Technology Department, ETRI </FONT>
<BR><FONT SIZE=2>Tel) 042-860-4922 </FONT>
<BR><FONT SIZE=2>Email) mjyang@etri.re.kr </FONT>
<BR><FONT SIZE=2>--------------------------------------</FONT>
<BR><FONT SIZE=2></FONT>&nbsp;
</P>

</BODY>
</HTML>
------_=_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <C99BZ1XG>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>[Isis-wg] IS-IS network size</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi, All</FONT>
</P>

<P><FONT SIZE=2>I have following questions about IS-IS network size practically.</FONT>
<BR><FONT SIZE=2>1. How many nodes(or routing entries) in one IS-IS area?</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; I want to know recommended number of nodes(routing entry) in one area</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; establishing IS-IS network.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Also, I need reference text or reference document about it.</FONT>
</P>

<P><FONT SIZE=2>2. Must Level2 router accomodate whole rouing entries in one AS?</FONT>
<BR><FONT SIZE=2>&nbsp; That is, maximum routing entry of Level 2 router is</FONT>
<BR><FONT SIZE=2>(number of nodes(routing entry) in one area) * (number of area in one AS) ?</FONT>
</P>

<P><FONT SIZE=2>Thanks in advance..</FONT>
<BR><FONT SIZE=2>-------------------------------------- </FONT>
<BR><FONT SIZE=2>Mijeong Yang </FONT>
</P>

<P><FONT SIZE=2>Internet Technology Department, ETRI </FONT>
<BR><FONT SIZE=2>Tel) 042-860-4922 </FONT>
<BR><FONT SIZE=2>Email) mjyang@etri.re.kr </FONT>
<BR><FONT SIZE=2>--------------------------------------</FONT>
</P>

</BODY>
</HTML>
------_=_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328560CA4@india_exch.hyderabad.mindspeed.com>
From: "Ramalingam, Swaminathan" <swaminathanr@netplane.com>
To: "'jparker@axiowave.com'" <jparker@axiowave.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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" <leontsinis@hotmail.com>
To: <mjyang@etri.re.kr>, <isis-wg@juniper.net>
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: <OE54NNmPrdKz1EQDSZG0000292f@hotmail.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<HTML><BODY STYLE=3D"font:10pt verdana; border:none;"><DIV>&nbsp;</DIV> <=
DIV>&nbsp;</DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: #000000 2px solid; MAR=
GIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">=
 <DIV style=3D"FONT: 10pt Arial">----- Original Message -----</DIV> <DIV =
style=3D"BACKGROUND: #e4e4e4; COLOR: black; FONT: 10pt Arial"><B>From:</B=
> mjyang@etri.re.kr</DIV> <DIV style=3D"FONT: 10pt Arial"><B>Sent:</B> 02=
 April 2002 07:04</DIV> <DIV style=3D"FONT: 10pt Arial"><B>To:</B> isis-w=
g@juniper.net</DIV> <DIV style=3D"FONT: 10pt Arial"><B>Subject:</B> [Isis=
-wg] IS-IS network size</DIV> <DIV>&nbsp;</DIV><!DOCTYPE HTML PUBLIC "-//=
W3C//DTD HTML 3.2//EN"> <META content=3D"MS Exchange Server version 5.5.2=
653.12" name=3DGenerator> <P><FONT size=3D2>Hi, All</FONT> </P> <P><FONT =
size=3D2>I have following questions about IS-IS network size practically.=
</FONT> <BR><FONT size=3D2>1. How many nodes(or routing entries) in one I=
S-IS area?</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; I want to know recommen=
ded number of nodes(routing entry) in one area</FONT> <BR><FONT size=3D2>=
&nbsp;&nbsp; establishing IS-IS network.</FONT> </P> <P>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. </P> <P><BR><FONT size=3D2>&nb=
sp;&nbsp; Also, I need reference text or reference document about it.</FO=
NT></P> <P>a good book is isis network design solutions cisco press I bou=
ght it recently&nbsp;</P> <P><FONT size=3D2>2. Must Level2 router accomod=
ate whole rouing entries in one AS?</FONT> </P> <P>i&nbsp;don't understan=
d the question. You are using IGP to route taffic in your AS ONLY.</P> <P=
><BR><FONT size=3D2>&nbsp; That is, maximum routing entry of Level 2 rout=
er is</FONT> <BR><FONT size=3D2>(number of nodes(routing entry) in one ar=
ea) * (number of area in one AS) ?</FONT> </P> <P>&nbsp;</P> <P><FONT siz=
e=3D2>Thanks in advance..</FONT> <BR><FONT size=3D2>---------------------=
----------------- </FONT><BR><FONT size=3D2>Mijeong Yang </FONT></P> <P><=
FONT size=3D2>Internet Technology Department, ETRI </FONT><BR><FONT size=3D=
2>Tel) 042-860-4922 </FONT><BR><FONT size=3D2>Email) mjyang@etri.re.kr </=
FONT><BR><FONT size=3D2>--------------------------------------</FONT> </P=
></BLOCKQUOTE></BODY></HTML><br clear=3Dall><hr>Get more from the Web.  F=
REE MSN Explorer download : <a href=3D'http://explorer.msn.com'>http://ex=
plorer.msn.com</a><br></p>

------=_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <dasnabendu@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <C99B52QJ>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>[=C8=B8=BD=C5] Re: [Isis-wg] IS-IS network size</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Thank you for your reply..</FONT>
</P>

<P><FONT SIZE=3D2>My second question means that</FONT>
</P>

<P><FONT SIZE=3D2>A level2 router receives all routing entries from all =
level1 routers in my area,</FONT>
<BR><FONT SIZE=3D2>then, the level2 router receives all routing entries =
from all level 2 routers in my AS in the worst case.</FONT>
<BR><FONT SIZE=3D2>So, maximum routing entry of Level 2 router is =
</FONT>
<BR><FONT SIZE=3D2>(number of nodes(routing entry) in one area) * =
(number of area in one AS).</FONT>
</P>

<P><FONT SIZE=3D2>Is it right?</FONT>
</P>

<P><FONT SIZE=3D2>Thaks in advance..</FONT>
<BR><FONT SIZE=3D2>Yang..</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>=BF=F8=BA=BB =B3=BB=BF=EB:</FONT>
</P>

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

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: mjyang@etri.re.kr</FONT>
<BR><FONT SIZE=3D2>Sent: 02 April 2002 07:04</FONT>
<BR><FONT SIZE=3D2>To: isis-wg@juniper.net</FONT>
<BR><FONT SIZE=3D2>Subject: [Isis-wg] IS-IS network size</FONT>
<BR><FONT SIZE=3D2>Hi, All</FONT>
<BR><FONT SIZE=3D2>I have following questions about IS-IS network size =
practically. </FONT>
<BR><FONT SIZE=3D2>1. How many nodes(or routing entries) in one IS-IS =
area? </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I want to know recommended number of =
nodes(routing entry) in one area </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; establishing IS-IS network.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>

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

<P><FONT SIZE=3D2>&nbsp; That is, maximum routing entry of Level 2 =
router is </FONT>
<BR><FONT SIZE=3D2>(number of nodes(routing entry) in one area) * =
(number of area in one AS) ?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advance.. </FONT>
<BR><FONT SIZE=3D2>-------------------------------------- </FONT>
<BR><FONT SIZE=3D2>Mijeong Yang </FONT>
<BR><FONT SIZE=3D2>Internet Technology Department, ETRI </FONT>
<BR><FONT SIZE=3D2>Tel) 042-860-4922 </FONT>
<BR><FONT SIZE=3D2>Email) mjyang@etri.re.kr </FONT>
<BR><FONT SIZE=3D2>--------------------------------------</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Get more from the Web. FREE MSN Explorer download : =
<A HREF=3D"http://explorer.msn.com" =
TARGET=3D"_blank">http://explorer.msn.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@external.juniper.net>; 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 <G03DMZDD>; Tue, 2 Apr 2002 12:47:29 -0500
Message-ID: <94B9091E1149D411A45C00508BACEB35015F2D18@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'stefano previdi'" <sprevidi@cisco.com>,
        Hannes Gredler
	 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <fenner@research.att.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@spider.juniper.net>; Tue, 2 Apr 2002 15:02:46 -0800
Message-ID: <3CAA1A52.A5396F3F@ipinfusion.com>
From: shuqin <shuqin@ipinfusion.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <HMP960MP>; Wed, 3 Apr 2002 12:01:54 -0800
Message-ID: <B4DFCB7CDE2DD4118F690008C78694160365B883@tahoe.allegronetworks.com>
From: Neal Castagnoli <cast@allegronetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
Date: Wed, 3 Apr 2002 12:01:53 -0800



> -----Original Message-----
> From: Tony Przygienda [mailto:prz@net4u.ch]


<snip>


> 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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <B0002228422@fsnt.future.futsoft.com> for <isis-wg@juniper.net>;
 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 <isis-wg@juniper.net>; Thu, 4 Apr 2002 16:28:54 +0530
Reply-To: <ramanann@future.futsoft.com>
From: "Ramanan" <ramanann@future.futsoft.com>
To: "Isis-Wg (E-mail)" <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <EB5FFC72F183D411B38200062957342901E56F81@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'ramanann@future.futsoft.com'" <ramanann@future.futsoft.com>,
        "Isis-Wg (E-mail)" <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <B0002234401@fsnt.future.futsoft.com>;
 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: <ramanann@future.futsoft.com>
From: "Ramanan" <ramanann@future.futsoft.com>
To: "'Jeff Parker'" <jparker@axiowave.com>,
        "'Isis-Wg (E-mail)'" <isis-wg@juniper.net>
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: <EB5FFC72F183D411B38200062957342901E56F81@r2d2.axiowave.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; Fri, 5 Apr 2002 06:49:41 -0800 (PST)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E56FC5@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "IS-IS-WG (E-mail)" <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <dasnabendu@yahoo.com>
From: mike shand <mshand@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@spider.juniper.net>; 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: <C77B73BC1A3ED4118C2000508BAD8A7C0350AF92@ma8117exch001u.bos.ascend.com>
From: "Miyagishima, Corwyn (Corwyn)" <corwyn@lucent.com>
To: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
Cc: "Sciandra, Francesco (Francesco)" <sciandra@lucent.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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)" <corwyn@lucent.com>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] IS-IS Restart Capability: receiving/processing
  "old" IIH packets?
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>,
        "Sciandra, Francesco (Francesco)" <sciandra@lucent.com>
In-Reply-To: <C77B73BC1A3ED4118C2000508BAD8A7C0350AF92@ma8117exch001u.bo
 s.ascend.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@spider.juniper.net>; 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: <C77B73BC1A3ED4118C2000508BAD8A7C0350AF93@ma8117exch001u.bos.ascend.com>
From: "Miyagishima, Corwyn (Corwyn)" <corwyn@lucent.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>,
        "Sciandra, Francesco (Francesco)" <sciandra@lucent.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Mon, 8 Apr 2002 11:39:05 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E5700C@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Mon, 8 Apr 2002 11:41:49 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E5700D@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <jparker@axiowave.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] Hello Multiplier - FINAL ROUND
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
In-Reply-To: <EB5FFC72F183D411B38200062957342901E5700C@r2d2.axiowave.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <HMP97MS4>; Mon, 8 Apr 2002 15:11:37 -0700
Message-ID: <B4DFCB7CDE2DD4118F690008C78694160365B8AC@tahoe.allegronetworks.com>
From: Neal Castagnoli <cast@allegronetworks.com>
To: "'Jeff Parker'" <jparker@axiowave.com>,
        "'isis-wg@spider.juniper.net'"
	 <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; Mon,  8 Apr 2002 14:57:59 -0700 (PDT)
Message-ID: <3CB1F321.CE193FBD@redback.com>
From: Tony Przygienda <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: 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <JRB@dataconnection.com>
To: "Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 05 Apr 2002 16:22:29 +0200
 <20020405162229.A4232@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Hannes Gredler <hannes@juniper.net>
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" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 05 Apr 2002 16:22:29 +0200
 <20020405162229.A4232@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Hannes Gredler <hannes@juniper.net>
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" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 05 Apr 2002 16:22:29 +0200
 <20020405162229.A4232@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Hannes Gredler <hannes@juniper.net>
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" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 05 Apr 2002 16:22:29 +0200
 <20020405162229.A4232@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Hannes Gredler <hannes@juniper.net>
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" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 05 Apr 2002 16:22:29 +0200
 <20020405162229.A4232@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Hannes Gredler <hannes@juniper.net>
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" <cmartin@gnilink.net>, bneal@broadwing.com,
        kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net,
        danny@tcb.net, prz@redback.com,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@external.juniper.net>; 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" <cmartin@gnilink.net>
To: "'Tony Przygienda'" <prz@redback.com>,
        "Martin, Christian"
	 <cmartin@gnilink.net>
Cc: "'stefano previdi'" <sprevidi@cisco.com>,
        Hannes Gredler
	 <hannes@juniper.net>, bneal@broadwing.com,
        Tony Li <tli@procket.com>, naiming@redback.com,
        Nischal Sheth <nsheth@juniper.net>,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "'Tony Przygienda'" <prz@redback.com>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        Tony Li <tli@procket.com>, naiming@redback.com,
        Nischal Sheth <nsheth@juniper.net>,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <hannes@juniper.net>
Cc: "Martin, Christian" <cmartin@gnilink.net>,
        "'Tony Przygienda'" <prz@redback.com>,
        "'stefano previdi'" <sprevidi@cisco.com>, bneal@broadwing.com,
        Tony Li <tli@procket.com>, Nischal Sheth <nsheth@juniper.net>,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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 <hannes@juniper.net> 
 dated Fri, 12 Apr 2002 01:10:47 +0200
 <20020412011047.A30283@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@external.juniper.net>; 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 <prz@redback.com>
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "'stefano previdi'" <sprevidi@cisco.com>,
        Hannes Gredler <hannes@juniper.net>, bneal@broadwing.com,
        Tony Li <tli@procket.com>, naiming@redback.com,
        Nischal Sheth <nsheth@juniper.net>,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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.
> <snip>>
> >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

>
>

<snip>

> >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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <all-ietf@loki.ietf.org>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <all-ietf@loki.ietf.org>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A3283B8102@india_exch.hyderabad.mindspeed.com>
From: "Jonnala, Nagi" <nagij@netplane.com>
To: "'tli@procket.net'" <tli@procket.net>,
        "'rja@extremenetworks.com'"
	 <rja@extremenetworks.com>
Cc: "'isis-wg@juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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" <nagij@netplane.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] ISIS Cryptographic Authentication - Replay
  attacks
Cc: <isis-wg@juniper.net>
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A3283B8102@india_exch.hyderaba
 d.mindspeed.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <tli@procket.com>
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" <nagij@netplane.com>
Cc: "'tli@procket.net'" <tli@procket.com>,
        "'rja@extremenetworks.com'" <rja@extremenetworks.com>,
        "'isis-wg@juniper.net'" <isis-wg@juniper.net>
Subject: [Isis-wg] ISIS Cryptographic Authentication - Replay attacks
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A3283B8102@india_exch.hyderabad.mindspeed.com>
References: <E7E13AAF2F3ED41197C100508BD6A3283B8102@india_exch.hyderabad.mindspeed.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <matthew.noble@riverstonenet.com>
To: "Mike Shand (E-mail)" <mshand@cisco.com>
Cc: "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <rsrivats@cisco.com>
To: Matthew Noble <matthew.noble@riverstonenet.com>
cc: "Mike Shand (E-mail)" <mshand@cisco.com>,
        "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
Subject: Re: [Isis-wg] receipt of CSNP's during restart
In-Reply-To: <000001c1e549$1049f460$8fdb14ac@ctron.com>
Message-ID: <Pine.GSO.4.44.0204160933440.20721-100000@router.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <matthew.noble@riverstonenet.com>
To: "'Radhika Srivatsa'" <rsrivats@cisco.com>,
        "Matthew Noble" <matthew.noble@riverstonenet.com>
Cc: "Mike Shand (E-mail)" <mshand@cisco.com>,
        "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
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: <Pine.GSO.4.44.0204160933440.20721-100000@router.cisco.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@external.juniper.net>; 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" <cmartin@gnilink.net>
To: "'isis-wg@external.juniper.net'" <isis-wg@spider.juniper.net>
Cc: "'stefano previdi'" <sprevidi@cisco.com>, Tony Li <tli@procket.com>,
        "'Tony Przygienda'" <prz@redback.com>,
        Hannes Gredler <hannes@juniper.net>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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
           <draft-martin-neal-policy-isis-admin-tags-05.txt>


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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <cmartin@gnilink.net>
Cc: "'isis-wg@external.juniper.net'" <isis-wg@spider.juniper.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, Tony Li <tli@procket.com>,
        "'Tony Przygienda'" <prz@redback.com>,
        Hannes Gredler <hannes@juniper.net>, bneal@broadwing.com
In-reply-to: Mail from "Martin, Christian" <cmartin@gnilink.net> 
 dated Tue, 16 Apr 2002 15:47:13 EDT
 <94B9091E1149D411A45C00508BACEB35015F2DAA@entmail.gnilink.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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
 ]            <draft-martin-neal-policy-isis-admin-tags-05.txt>
 ] 
 ] 
 ] 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 <isis-archive@odin.ietf.org>; 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 <isis-wg@external.juniper.net>; 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" <cmartin@gnilink.net>
To: "'Naiming Shen'" <naiming@redback.com>,
        "Martin, Christian"
	 <cmartin@gnilink.net>
Cc: "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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
> ]            <draft-martin-neal-policy-isis-admin-tags-05.txt>
> ] 
> ] 
> ] 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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <prz@net4u.ch>
Subject: Re: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt -
 additions and c orrections
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "'isis-wg@external.juniper.net'" <isis-wg@spider.juniper.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, Tony Li <tli@procket.com>,
        "'Tony Przygienda'" <prz@redback.com>,
        Hannes Gredler <hannes@juniper.net>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <JDV8KB0C>; Wed, 17 Apr 2002 13:23:19 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DB5@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'Tony Przygienda'" <prz@net4u.ch>,
        "Martin, Christian"
	 <cmartin@gnilink.net>
Cc: "'isis-wg@external.juniper.net'" <isis-wg@spider.juniper.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, Tony Li <tli@procket.com>,
        "'Tony Przygienda'" <prz@redback.com>,
        Hannes Gredler <hannes@juniper.net>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <HZKJ45WB>; Wed, 17 Apr 2002 10:46:22 -0700
Message-ID: <C61C9973831E2949A9AA57F3B031846405D34A@exch-srv.CoronaNetworks.com>
From: Vairamuthu Karuppiah <muthu@coronanetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <dkatz@juniper.net>
To: muthu@coronanetworks.com
CC: isis-wg@juniper.net
In-reply-to: 
	<C61C9973831E2949A9AA57F3B031846405D34A@exch-srv.CoronaNetworks.com>
	(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:  <C61C9973831E2949A9AA57F3B031846405D34A@exch-srv.CoronaNetworks.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <prz@redback.com>
Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-06.txt
To: Dave Katz <dkatz@juniper.net>
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: 
 <C61C9973831E2949A9AA57F3B031846405D34A@exch-srv.CoronaNetworks.com>
 <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <prz@redback.com>
Subject: Re: [Isis-wg] draft-martin-neal-policy-isis-admin-tags-05.txt -
 additions and c orrections
To: "Martin, Christian" <cmartin@gnilink.net>
Cc: "'Tony Przygienda'" <prz@net4u.ch>,
        "'isis-wg@external.juniper.net'" <isis-wg@spider.juniper.net>,
        "'stefano previdi'" <sprevidi@cisco.com>, Tony Li <tli@procket.com>,
        Hannes Gredler <hannes@juniper.net>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <JDV8KB0K>; Wed, 17 Apr 2002 13:24:12 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB35015F2DB6@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "Martin, Christian" <cmartin@gnilink.net>,
        "'Tony Przygienda'"
	 <prz@net4u.ch>
Cc: "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <matthew.noble@riverstonenet.com>
From: mike shand <mshand@cisco.com>
Cc: "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <rsrivats@cisco.com>
To: mike shand <mshand@cisco.com>
cc: Matthew Noble <matthew.noble@riverstonenet.com>,
        "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
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: <Pine.GSO.4.44.0204181526070.16049-100000@router.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <Ravindra.Sunkad@VivaceNetworks.com>
From: Jeff Learman <jlearman@cisco.com>
Cc: isis-wg@spider.juniper.net
In-Reply-To: <A1F1542E2000FE40B5F0CDA3BA2D80E05D6DE1@po1.vivacenetworks.
 com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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>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"

<html>
<br>
(Changing the group to isis-wg.)<br>
<br>
At 04:03 PM 4/18/2002, Ravindra Sunkad wrote: <br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Sections
4.2 and 4.3 of
<a href="http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt</a>
do discuss IP forwarding over unnumbered LAN interfaces. Then again this applies only to LANs that are simulating PT-PT operation.</font></blockquote><br>
Thanks, Ravi, I missed that one somehow.&nbsp; It's probably in my<br>
&quot;stuff I gotta read&quot; folder ;-)<br>
<br>
Concerning the draft:<br>
<br>
(4.1 paragraph 2)&nbsp; What's an &quot;unnumbered IP address&quot;?&nbsp;&nbsp; Does this<br>
paragraph mean that an address must be advertised in IIH PDUs, but the<br>
same address may be used on other point-to-point circuits on the same<br>
router?<br>
<br>
Why wasn't a standard multicast address chosen to avoid the need for ARP?<br>
<br>
ARP shouldn't be required when using ISIS anyway, since IIHs are sufficient<br>
for MAC address resolution.&nbsp; And if ARP isn't required, then the interface<br>
IP address wouldn't be required either, I believe.&nbsp; But if a standard<br>
multicast address is used, the issue becomes moot.<br>
<br>
(Sorry for the johnny-come-lately questions.)<br>
<br>
Thanks,<br>
Jeff<br>
</html>

--=====================_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <jlearman@cisco.com>
Cc: "Ravindra Sunkad" <Ravindra.Sunkad@vivacenetworks.com>,
        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 <jlearman@cisco.com> 
 dated Thu, 18 Apr 2002 16:41:04 EDT
 <4.3.2.7.2.20020418162330.01e4f008@dingdong.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <naiming@redback.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt 
Cc: "Ravindra Sunkad" <Ravindra.Sunkad@vivacenetworks.com>,
        isis-wg@spider.juniper.net
In-Reply-To: <20020418215301.8FE7D4BA215@prattle.redback.com>
References: <Mail from Jeff Learman <jlearman@cisco.com>
 <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <jlearman@cisco.com>
Cc: "Ravindra Sunkad" <Ravindra.Sunkad@vivacenetworks.com>,
        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 <jlearman@cisco.com> 
 dated Thu, 18 Apr 2002 18:37:41 EDT
 <4.3.2.7.2.20020418182503.01e5aa30@dingdong.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <ginsberg@pluris.com>
To: "'Jeff Learman'" <jlearman@cisco.com>,
        Naiming Shen
	 <naiming@redback.com>
Cc: Ravindra Sunkad <Ravindra.Sunkad@vivacenetworks.com>,
        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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <rsrivats@cisco.com>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] Re: receipt of CSNP's during restart
Cc: Matthew Noble <matthew.noble@riverstonenet.com>,
        "'Isis-Wg (E-mail)" <isis-wg@spider.juniper.net>
In-Reply-To: <Pine.GSO.4.44.0204181526070.16049-100000@router.cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <ginsberg@pluris.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt 
Cc: Naiming Shen <naiming@redback.com>,
        Ravindra Sunkad <Ravindra.Sunkad@vivacenetworks.com>,
        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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Fri, 19 Apr 2002 07:17:05 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E571E3@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Jeff Learman'" <jlearman@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <jparker@axiowave.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt 
Cc: isis-wg@spider.juniper.net
In-Reply-To: <EB5FFC72F183D411B38200062957342901E571E3@r2d2.axiowave.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <prz@redback.com>
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 <jparker@axiowave.com>
Cc: "'Jeff Learman'" <jlearman@cisco.com>, isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt
References: <EB5FFC72F183D411B38200062957342901E571E3@r2d2.axiowave.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; Fri, 19 Apr 2002 12:41:43 -0700 (PDT)
Message-ID: <3CC0619C.5BE59482@redback.com>
From: Tony Przygienda <prz@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <jlearman@cisco.com>
Cc: Les Ginsberg <ginsberg@pluris.com>,
        Ravindra Sunkad <Ravindra.Sunkad@vivacenetworks.com>,
        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 <jlearman@cisco.com> 
 dated Fri, 19 Apr 2002 10:11:02 EDT
 <4.3.2.7.2.20020419093101.035eb2a8@dingdong.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <sprevidi@cisco.com>
To: Naiming Shen <naiming@redback.com>, Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt
X-Mailer: KMail [version 1.3.1]
Cc: Les Ginsberg <ginsberg@pluris.com>,
        Ravindra Sunkad <Ravindra.Sunkad@vivacenetworks.com>,
        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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <lqmao@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <JDW4QH2N>; Sat, 20 Apr 2002 12:45:44 +0100
Message-ID: <4103264BC8D3D51180B7002048400C454FB635@zhard0jd.europe.nortel.com>
From: "Philip Christian"<christi@nortelnetworks.com>
To: "'Lawrence Mao'" <lqmao@yahoo.com>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] IS-IS on UPSR ring</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I cannot answer the question about unidirectional =
rings. UPSR is a North American thing. My expertise is International =
market SDH.</FONT></P>

<P><FONT SIZE=3D2>However I can give you an OPINION on the second =
question,</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.&nbsp; 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.</FONT></P>

<P><FONT SIZE=3D2>If a link is unnumbered then I suppose that you =
should put your circuitless interface IP address in as the =
&quot;Interface IP address&quot; TLV in Hellos.&nbsp; I haven't figured =
out yet if this will enable ICMP redirects to work on LAN =
ports.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.&nbsp; However if there are no hosts, just two routers then you =
can't rely on ARP working.</FONT></P>

<P><FONT SIZE=3D2>You could argue that ARP and correct subnetting isn't =
needed for connecting two routers together.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>That's my opinion.</FONT>
</P>

<P><FONT SIZE=3D2>Philip</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Lawrence Mao [<A =
HREF=3D"mailto:lqmao@yahoo.com">mailto:lqmao@yahoo.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, April 20, 2002 12:33 AM</FONT>
<BR><FONT SIZE=3D2>To: isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>Subject: [Isis-wg] IS-IS on UPSR ring</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>If the IS-IS needs to be supported on a SONET</FONT>
<BR><FONT SIZE=3D2>UPSR ring, throught its DCC channel (note =
that</FONT>
<BR><FONT SIZE=3D2>the ring is uni-directional), say, if I have =
4</FONT>
<BR><FONT SIZE=3D2>nodes on a ring:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; A --&gt; B --&gt; C --&gt; D =
-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; =
^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; |--------------------</FONT>
</P>

<P><FONT SIZE=3D2>what kind of modifications need to be made in</FONT>
<BR><FONT SIZE=3D2>order to let the protocol work properly (note</FONT>
<BR><FONT SIZE=3D2>all interfaces are p2p type)?</FONT>
</P>

<P><FONT SIZE=3D2>2nd question is, if the interface is =
unnumbered,</FONT>
<BR><FONT SIZE=3D2>how is its routing table generated? Use =
routerID?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Lawrence</FONT>
</P>

<P><FONT =
SIZE=3D2>__________________________________________________</FONT>
<BR><FONT SIZE=3D2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>Yahoo! Tax Center - online filing with =
TurboTax</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://taxes.yahoo.com/" =
TARGET=3D"_blank">http://taxes.yahoo.com/</A></FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Isis-wg mailing list&nbsp; -&nbsp; =
Isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://spider.juniper.net/mailman/listinfo/isis-wg" =
TARGET=3D"_blank">http://spider.juniper.net/mailman/listinfo/isis-wg</A>=
</FONT>
</P>

</BODY>
</HTML>
------_=_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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <dkatz@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <dkatz@juniper.net>
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 <dkatz@juniper.net> 
 dated Sat, 20 Apr 2002 10:31:16 PDT
 <200204201731.g3KHVGU03946@cirrus.juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <lqmao@yahoo.com>
From: Jeff Learman <jlearman@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <JDW4R47A>; Mon, 22 Apr 2002 15:26:32 +0100
Message-ID: <4103264BC8D3D51180B7002048400C454FB63A@zhard0jd.europe.nortel.com>
From: "Philip Christian"<christi@nortelnetworks.com>
To: "'Jeff Learman'" <jlearman@cisco.com>, Lawrence Mao <lqmao@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] IS-IS on UPSR ring</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Specifically (according to G.7712):-</FONT>
</P>

<P><FONT SIZE=3D2>IP-only Integrated IS-IS NEs use PPP over HDLC in =
DCC.</FONT>
<BR><FONT SIZE=3D2>OSI-only IS-IS NEs use LAPD over DCC.</FONT>
<BR><FONT SIZE=3D2>Dual Integrated IS-IS NEs need a switchable (PPP or =
LAPD) data link layer.</FONT>
</P>

<P><FONT SIZE=3D2>Philip</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Jeff Learman [<A =
HREF=3D"mailto:jlearman@cisco.com">mailto:jlearman@cisco.com</A>]</FONT>=

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

</BODY>
</HTML>
------_=_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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <truskows@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <truskows@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] IS-IS on UPSR ring</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Specifically (according to G.7712):-</FONT>
</P>

<P><FONT SIZE=3D2>IP-only Integrated IS-IS NEs use PPP over HDLC in =
DCC.</FONT>
<BR><FONT SIZE=3D2>OSI-only IS-IS NEs use LAPD over DCC.</FONT>
<BR><FONT SIZE=3D2>Dual Integrated IS-IS NEs need a switchable (PPP or =
LAPD) data link layer.</FONT>
</P>

<P><FONT SIZE=3D2>Philip</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Jeff Learman [<A =
HREF=3D"mailto:jlearman@cisco.com">mailto:jlearman@cisco.com</A>]</FONT>=

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

</BODY>
</HTML>

--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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <nsheth@juniper.net>
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 <naiming@redback.com>
CC: Dave Katz <dkatz@juniper.net>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <lqmao@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <nsheth@juniper.net>
Cc: Naiming Shen <naiming@redback.com>, Dave Katz <dkatz@juniper.net>,
        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 <nsheth@juniper.net> 
 dated Mon, 22 Apr 2002 10:53:42 PDT
 <3CC44E26.4090909@juniper.net> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291CDF@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <VishwasM@netplane.com>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A328291CDF@india_exch.hyderaba
 d.mindspeed.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291CE9@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; Tue, 23 Apr 2002 19:45:55 -0400 (EDT)
Message-Id: <200204232345.TAA10336@bcn.East.Sun.COM>
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <tli@procket.com>
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 <Radia.Perlman@sun.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <ginsberg@pluris.com>
To: "'Radia Perlman - Boston Center for Networking'" <Radia.Perlman@sun.com>,
        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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <naiming@redback.com>
From: mike shand <mshand@cisco.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291CFD@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <VishwasM@netplane.com>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A328291CFD@india_exch.hyderaba
 d.mindspeed.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Wed, 24 Apr 2002 07:21:17 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E57273@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Les  Ginsberg'" <ginsberg@pluris.com>,
        "'Radia Perlman - Boston Center for Networking'" <Radia.Perlman@sun.com>
Cc: "IS-IS-WG (E-mail)" <isis-wg@spider.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"
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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)" <isis-wg@spider.juniper.net>
To: Jeff Parker <jparker@axiowave.com>
From: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <EB5FFC72F183D411B38200062957342901E57273@r2d2.axiowave.com>
Message-Id: <AF358E52-5797-11D6-8E71-00039357A82A@extremenetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Wed, 24 Apr 2002 08:27:27 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E57280@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'RJ Atkinson'" <rja@extremenetworks.com>,
        Jeff Parker
	 <jparker@axiowave.com>
Cc: "IS-IS-WG (E-mail)" <isis-wg@spider.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"
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291D00@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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)" <isis-wg@spider.juniper.net>
To: Jeff Parker <jparker@axiowave.com>
From: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <EB5FFC72F183D411B38200062957342901E57280@r2d2.axiowave.com>
Message-Id: <EC5732B4-57B2-11D6-B5B7-00039357A82A@extremenetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <EB5FFC72F183D411B38200062957342901E57296@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Radia Perlman - Boston Center for Networking'" <Radia.Perlman@sun.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <zinin@psg.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <6629208368.20020424153556@psg.com>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <ginsberg@pluris.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <tli@procket.com>
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 <Radia.Perlman@sun.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291D04@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <VishwasM@netplane.com>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A328291D00@india_exch.hyderaba
 d.mindspeed.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291D05@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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" <VishwasM@netplane.com>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A328291D04@india_exch.hyderaba
 d.mindspeed.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <E7E13AAF2F3ED41197C100508BD6A328291D06@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'mike shand'" <mshand@cisco.com>
Cc: "'isis-wg@spider.juniper.net'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: mike shand <mshand@cisco.com>
cc: Naiming Shen <naiming@redback.com>, 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: <Pine.GSO.4.21.0204250824580.45-100000@uzura.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; Thu, 25 Apr 2002 20:43:22 +0800 
Message-ID: <000f01c1ede9$3d485d00$3b336e0a@HUAWEI.COM>
From: "Wang xuepu" <wangxp@huawei.com>
To: <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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'" <Radia.Perlman@sun.com>,
        isis-wg@juniper.net
To: Jeff Parker <jparker@axiowave.com>
From: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <EB5FFC72F183D411B38200062957342901E57296@r2d2.axiowave.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Thu, 25 Apr 2002 07:36:17 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E572A2@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'RJ Atkinson'" <rja@extremenetworks.com>
Cc: "IS-IS-WG (E-mail)" <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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" <wangxp@huawei.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] About  MTU?
Cc: <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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"

<html>
<br>
ISO 10589:1992 is not clear what should be done in this case -- the<br>
answer seems to be to purge the PDU.<br>
<br>
ISO 10589:2001 clears up what the router should do, but it doesn't<br>
solve the problem -- it just makes the problem less severe and
defines<br>
management events to help indicate the existence of the problem.<br>
<br>
It's a configuration error, and the network administrator must fix
it<br>
by reducing the maximum originate LSP size on all routers in the<br>
subdomain (area or L2 backbone).<br>
<br>
Regards,<br>
Jeff<br>
<br>
At 08:44 AM 4/27/2002, Wang xuepu wrote:<br>
<blockquote type=cite cite><font size=2>Suppose there are three routers
in the same area,and they are connected by the ethernet.</font><br>
<font size=2>such as:</font><br>
&nbsp;<br>
<font size=2>&nbsp;___&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
___&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ___&nbsp;&nbsp;&nbsp;
</font><br>
<font size=2>| A |______| B |_______| C | </font><br>
<font size=2>|___|e0&nbsp; e0|___|e1&nbsp;&nbsp; e0|___|</font><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>Suppose:</font><br>
<font size=2>Router A: </font><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of
e0 is 1500.</font><br>
<font size=2>Router B:</font><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of
e0 is 1500.&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of
e1 is 1000.&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>Router C:</font><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of
e0 is 1000.&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>Now:</font><br>
<font size=2>When Router B receive a Router A's LSP from e0,the size of
this LSP should be 1500,the Router B should flood</font><br>
<font size=2>the LSP,but B can not send this LSP throught e1.becase the
mtu is too small.</font><br>
<font size=2>Is it correct?</font><br>
<font size=2>if it is right,how can we solute this problem?</font><br>
&nbsp;</blockquote></html>

--=====================_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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <ginsberg@pluris.com>
To: "'Wang xuepu '" <wangxp@huawei.com>,
        "'isis-wg@juniper.net '"
	 <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <A1F1542E2000FE40B5F0CDA3BA2D80E01E8A9D@po1.vivacenetworks.com>
Thread-Topic: [Isis-wg] About  MTU?
Thread-Index: AcHsd7d3SgQxFlkiRt6MRtB7cjVUYAAABCGA
From: "Ravindra Sunkad" <Ravindra.Sunkad@VivaceNetworks.com>
To: "Jeff Learman" <jlearman@cisco.com>, "Wang xuepu" <wangxp@huawei.com>
Cc: <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D375343916-25042002><FONT face=3DArial color=3D#0000ff =
size=3D2>If an=20
implementation brings down IS-IS&nbsp;on&nbsp;interfaces with MTU &lt;=20
LSP_BUF_SIZE this problem will not arise.</FONT></SPAN></DIV>
<DIV><SPAN class=3D375343916-25042002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B> Jeff=20
Learman [mailto:jlearman@cisco.com] <BR><B>Sent:</B> Thursday, April 25, =
2002=20
8:13 AM<BR><B>To:</B> Wang xuepu<BR><B>Cc:</B>=20
isis-wg@juniper.net<BR><B>Subject:</B> Re: [Isis-wg] About=20
MTU?<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR>ISO 10589:1992 is not =
clear what=20
  should be done in this case -- the<BR>answer seems to be to purge the=20
  PDU.<BR><BR>ISO 10589:2001 clears up what the router should do, but it =

  doesn't<BR>solve the problem -- it just makes the problem less severe =
and=20
  defines<BR>management events to help indicate the existence of the=20
  problem.<BR><BR>It's a configuration error, and the network =
administrator must=20
  fix it<BR>by reducing the maximum originate LSP size on all routers in =

  the<BR>subdomain (area or L2 =
backbone).<BR><BR>Regards,<BR>Jeff<BR><BR>At=20
  08:44 AM 4/27/2002, Wang xuepu wrote:<BR>
  <BLOCKQUOTE cite type=3D"cite"><FONT size=3D2>Suppose there are three =
routers in=20
    the same area,and they are connected by the =
ethernet.</FONT><BR><FONT=20
    size=3D2>such as:</FONT><BR>&nbsp;<BR><FONT=20
    size=3D2>&nbsp;___&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    ___&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
___&nbsp;&nbsp;&nbsp;=20
    </FONT><BR><FONT size=3D2>| A |______| B |_______| C | =
</FONT><BR><FONT=20
    size=3D2>|___|e0&nbsp; e0|___|e1&nbsp;&nbsp; e0|___|</FONT><BR><FONT =

    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
    size=3D2>Suppose:</FONT><BR><FONT size=3D2>Router A: =
</FONT><BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of =
e0 is=20
    1500.</FONT><BR><FONT size=3D2>Router B:</FONT><BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of =
e0 is=20
    1500.&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of =
e1 is=20
    1000.&nbsp;&nbsp;&nbsp; </FONT><BR><FONT size=3D2>Router =
C:</FONT><BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mtu of =
e0 is=20
    1000.&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>Now:</FONT><BR><FONT=20
    size=3D2>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</FONT><BR><FONT =
size=3D2>the LSP,but=20
    B can not send this LSP throught e1.becase the mtu is too=20
    small.</FONT><BR><FONT size=3D2>Is it correct?</FONT><BR><FONT =
size=3D2>if it is=20
    right,how can we solute this=20
problem?</FONT><BR>&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
=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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <isis-wg@juniper.net>; 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 <ramsrm@tdd.sj.nec.com>
Reply-To: "ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com>
To: "isis-wg@juniper.net" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <zinin@psg.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <44105465351.20020425124647@psg.com>
To: ramanathan rams <ramsrm@tdd.sj.nec.com>
CC: "isis-wg@juniper.net" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <EB5FFC72F183D411B38200062957342901E572CE@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'ramsrm@tdd.sj.nec.com'" <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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <prz@redback.com>
Subject: Re: [Isis-wg] About  MTU?
To: Ravindra Sunkad <Ravindra.Sunkad@vivacenetworks.com>
Cc: Jeff Learman <jlearman@cisco.com>, Wang xuepu <wangxp@huawei.com>,
        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: <A1F1542E2000FE40B5F0CDA3BA2D80E01E8A9D@po1.vivacenetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <prz@redback.com>
Subject: Re: [Isis-wg] About  MTU?
To: Ravindra Sunkad <Ravindra.Sunkad@VivaceNetworks.com>
Cc: Jeff Learman <jlearman@cisco.com>, Wang xuepu <wangxp@huawei.com>,
        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: <A1F1542E2000FE40B5F0CDA3BA2D80E01E8AA0@po1.vivacenetworks.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <A1F1542E2000FE40B5F0CDA3BA2D80E01E8AA0@po1.vivacenetworks.com>
Thread-Topic: [Isis-wg] About  MTU?
Thread-Index: AcHsyPP8JisHArKaR1u0OOfxuMChJQAAHQMg
From: "Ravindra Sunkad" <Ravindra.Sunkad@VivaceNetworks.com>
To: <prz@redback.com>
Cc: "Jeff Learman" <jlearman@cisco.com>, "Wang xuepu" <wangxp@huawei.com>,
        <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <ginsberg@pluris.com>
To: "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>, prz@redback.com
Cc: Jeff Learman <jlearman@cisco.com>, Wang xuepu <wangxp@huawei.com>,
        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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <B0002383744@fsnt.future.futsoft.com>;
 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: <selvarajr@future.futsoft.com>
From: "SelvarajR" <selvarajr@future.futsoft.com>
To: <prz@redback.com>,
        "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>
Cc: "'Jeff Learman'" <jlearman@cisco.com>, "'Wang xuepu'" <wangxp@huawei.com>,
        <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <riw@cisco.com>
Cc: mike shand <mshand@cisco.com>, Naiming Shen <naiming@redback.com>,
        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 <ruwhite@cisco.com> 
 dated Thu, 25 Apr 2002 08:30:33 EDT
 <Pine.GSO.4.21.0204250824580.45-100000@uzura.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <prz@net4u.ch>
Subject: Re: [Isis-wg] *SNP replay
To: Jeff Parker <jparker@axiowave.com>
Cc: "'RJ Atkinson'" <rja@extremenetworks.com>,
        "IS-IS-WG (E-mail)" <isis-wg@spider.juniper.net>
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: <EB5FFC72F183D411B38200062957342901E572A2@r2d2.axiowave.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <prz@redback.com>
Subject: Re: [Isis-wg] About  MTU?
To: selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>,
        "'Jeff Learman'" <jlearman@cisco.com>,
        "'Wang xuepu'" <wangxp@huawei.com>, 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; Fri, 26 Apr 2002 07:11:04 -0700 (PDT)
	(envelope-from jparker@axiowave.com)
Message-ID: <EB5FFC72F183D411B38200062957342901E572E0@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Tony Przygienda'" <prz@net4u.ch>,
        "Les Ginsberg (E-mail)"
	 <ginsberg@pluris.com>
Cc: "'RJ Atkinson'" <rja@extremenetworks.com>,
        "IS-IS-WG (E-mail)"
	 <isis-wg@spider.juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <EB5FFC72F183D411B38200062957342901E572E1@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'prz@redback.com'" <prz@redback.com>, selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>,
        "'Jeff Learman'"
	 <jlearman@cisco.com>,
        "'Wang xuepu'" <wangxp@huawei.com>, isis-wg@juniper.net,
        "Les Ginsberg (E-mail)" <ginsberg@pluris.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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.

<EOT>

> 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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <dasnabendu@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <prz@net4u.ch>
Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture
To: nabendu das <dasnabendu@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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: <C7DF4400240AFB4095D98C7C6EC2A34A5DE0F0@bart.cwnt.com>
Thread-Topic: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Thread-Index: AcHsL6SAESx2F6ylTfSTzYEiPCSV1QClkhcw
From: "Amir Hermelin" <amir@cwnt.com>
To: "Manral, Vishwas" <VishwasM@netplane.com>
Cc: <isis-wg@spider.juniper.net>, "Amir Hermelin" <amir@cwnt.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Naiming Shen <naiming@redback.com>
cc: mike shand <mshand@cisco.com>, 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: <Pine.GSO.4.21.0204282127240.21483-100000@ruwhite-u10.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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: <selvarajr@future.futsoft.com>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] About  MTU?
Cc: <prz@redback.com>,
        "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>,
        "'Jeff Learman'" <jlearman@cisco.com>,
        "'Wang xuepu'" <wangxp@huawei.com>, <isis-wg@juniper.net>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <isis-wg@juniper.net>; 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 <tli@procket.com>
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 <dasnabendu@yahoo.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@lists.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <mshand@cisco.com>
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 <mshand@cisco.com> 
 dated Wed, 24 Apr 2002 14:53:26 BST
 <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@spider.juniper.net>; 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 <riw@cisco.com>
Cc: mike shand <mshand@cisco.com>, 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 <ruwhite@cisco.com> 
 dated Sun, 28 Apr 2002 21:31:26 EDT
 <Pine.GSO.4.21.0204282127240.21483-100000@ruwhite-u10.cisco.com> 
From: Naiming Shen <naiming@redback.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <isis-archive@odin.ietf.org>; 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 <isis-wg@external.juniper.net>; 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 <GSBS2M23>; Tue, 30 Apr 2002 15:44:40 -0700
Message-ID: <B7E68CA26CF93846B74B9305EE908AE61DBBEF@viva1.vivacenetworks.com>
From: Hema Malik <Hema.Malik@vivacenetworks.com>
To: "'isis-wg@external.juniper.net'" <isis-wg@spider.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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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 <prz@redback.com>
Subject: Re: [Isis-wg] About  MTU?
To: selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>,
   "'Jeff Learman'" <jlearman@cisco.com>, "'Wang xuepu'"
<wangxp@huawei.com>,
   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 <jparker@axiowave.com>
To: "'Tony Przygienda'" <prz@net4u.ch>,
   "Les Ginsberg (E-mail)"
	 <ginsberg@pluris.com>
Cc: "'RJ Atkinson'" <rja@extremenetworks.com>,
   "IS-IS-WG (E-mail)"
	 <isis-wg@spider.juniper.net>
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 <jparker@axiowave.com>
To: "'prz@redback.com'" <prz@redback.com>, selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" <Ravindra.Sunkad@vivacenetworks.com>,
   "'Jeff Learman'"
	 <jlearman@cisco.com>, "'Wang xuepu'" <wangxp@huawei.com>,
   isis-wg@juniper.net, "Les Ginsberg (E-mail)" <ginsberg@pluris.com>
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.

<EOT>

> 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 <dasnabendu@yahoo.com>
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 <prz@net4u.ch>
Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture
To: nabendu das <dasnabendu@yahoo.com>
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" <amir@cwnt.com>
To: "Manral, Vishwas" <VishwasM@netplane.com>
Cc: <isis-wg@spider.juniper.net>, "Amir Hermelin" <amir@cwnt.com>

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 <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Naiming Shen <naiming@redback.com>
cc: mike shand <mshand@cisco.com>, 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