From isis-wg-admin@spider.juniper.net Sun Feb 4 12:19:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09834 for ; Sun, 4 Feb 2001 12:19:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA99192; Sun, 4 Feb 2001 09:49:03 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA99177 for ; Sun, 4 Feb 2001 09:47:51 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 4 Feb 2001 19:16:14 +0200 Message-ID: <02d601c08ee0$186ba460$2c00a8c0@amir> From: "Amir H." To: "ISIS-wg" References: <019101c083b9$ca0ad5b0$2c00a8c0@amir><4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> <14960.27235.756698.965617@alpha-tli.procket.com> Subject: Re: [Isis-wg] Re: draft-hermelin-ext-lsp-frags-00.txt Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 04 Feb 2001 17:16:14.0182 (UTC) FILETIME=[2D5C8860:01C08ECE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 4 Feb 2001 19:24:29 -0000 Content-Transfer-Encoding: 7bit (Sorry for switching the subject line, should've done it from the beginning) Apparently, I was too hasty to dispose of the ECMP option. I don't think that non-determinism is an issue, as RFC 1195 doesn't require any determinism of IP paths greater than the MaxPathSplits. Even if some vendors do employ determinism, that would not guarantee determinism in multi-vendor environments. However, I agree that disposal of ECMP in the presence of extended-LSPs is a bad idea. Especially since not only multiple paths to the extended-LSP might be eliminated, but also paths to the original LSP (take Naming's example, there is symmetry between B and B"). For anyone that's confused, at least one path will still remain to all destinations. The options I see as available right now are: a) Don't advertise adjacencies in extended LSPs, as the original text suggests. This has the advantage of avoiding zero-cost loops. This has the dis-advantage of not being scalable in the presence of huge adjacency information (over a thousand adjacencies advertising full TE information) limited to only the original LSPs. b) Advertise adjacencies off extended LSPs. This has the advantage of being scalable to almost unlimited link-state information. However, it has the strong dis-advantage of introducing zero-cost loops, and as a result loss of equal-cost routes to some destinations. c) Hybrid approach: use option (a) until the original LSPs have no more room to hold adjacency information, then start advertising adjacencies off extended LSPs. I don't like this one (since a single adjacency addition could force a lot of ECMP paths to use just a single path), but it might be better than the former two. In any case, any of these options is better than not advertising the information at all. New options/opinions on these three are more than welcomed. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com In Simplicity there is Elegance(TM) Tel: 972-4-9592203 ext. 222 Fax: 972-4-9593325 2 Ha'Mada St., POB 333, Yokneam Moshava 20600, ISRAEL. ----- Original Message ----- From: "Tony Li" To: "mike shand" Cc: "Naiming Shen" ; "Amir H." ; "Tony Li" ; "ISIS-wg" Sent: Thursday, January 25, 2001 6:03 PM Subject: Re: [Isis-wg] Re: New Internet-Draft > > | I imagine that we could modify the SPF algorithm to deal with this (e.g. by > | selectively permitting additions to the adjacency set of nodes already on > | PATHS, or by unwrapping the zero cost links onto TENT, while keeping track > | of possible loops), but that is not the point. The whole rationale for this > | proposal is that we can allow certain nodes to expand their LSP set WITHOUT > | requiring any changes in the other nodes, and in particular any changes to > | their SPFs. > | > | So I guess the question is, do we care about the failure to make use of > | potential path splits? I think we do. > > > I concur. And I agree that a solution that required no changes to existing > systems would be preferable. Any suggestions? > > Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 14 22:23:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22883 for ; Wed, 14 Feb 2001 22:23:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA59281; Wed, 14 Feb 2001 19:53:02 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA52199 for ; Tue, 13 Feb 2001 13:34:00 -0800 (PST) Received: from router.cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA25552 for ; Tue, 13 Feb 2001 13:01:36 -0800 (PST) From: Radhika Srivatsa To: isis-wg@spider.juniper.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Isis-wg] Question about a ISIS MIB variable Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 13 Feb 2001 16:01:18 -0500 (EST) Hi, I have a question regarding the following variable in the isisCirc table of the ISIS MIB draft: isisCircOutCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs sent on this circuit." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisCircEntry 17 } What exactly in the isis protocol make up the control PDUs ? Are they CSNP, PSNP and the Hello PDUs ? Does control PDUs include the LSPs too but I think LSP would be mostly categorized as data PDUs ? Thanks. -Radhika ------------------------------------------------------------------------ Radhika Srivatsa HFR Software Development Phone: 734-302-4134 Cisco Systems Fax: 734-302-4190 Ann Arbor, MI 48104 Email: rsrivats@cisco.com ------------------------------------------------------------------------ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 15 09:07:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17574 for ; Thu, 15 Feb 2001 09:07:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA61917; Thu, 15 Feb 2001 06:38:02 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA61905 for ; Thu, 15 Feb 2001 06:37:10 -0800 (PST) Message-ID: From: Jeff Parker To: "'Radhika Srivatsa'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question about a ISIS MIB variable 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 15 Feb 2001 09:04:06 -0500 > isisCircOutCtrlPDUs OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of IS-IS control PDUs sent on this circuit." > REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" > ::= { isisCircEntry 17 } > > What exactly in the isis protocol make up the control PDUs ? Are they > CSNP, PSNP and the Hello PDUs ? > > Does control PDUs include the LSPs too but I think LSP would be mostly > categorized as data PDUs ? > > -Radhika Radhika - Good question. I would argue that user traffic makes up the Data PDUs, and the control traffic is what is used to control the forwarding. The reference is circular... iSISControlPDUsReceived ATTRIBUTE DERIVED FROM "Rec. X.723 | ISO/IEC 10165-5":nonWrappingCounter; BEHAVIOUR iSISControlPDUsReceived-B BEHAVIOUR DEFINED AS Number of control PDUs received on this circuit;; REGISTERED AS {ISIS.aoi iSISControlPDUsReceived (44)}; But there is a reference in 7.4.4 that says "Control traffic (LSPs, Sequence Numbers PDUs)...." which would indicate everything except the Hellos. This clearly need clarification, and perhaps modification. I would prefer to see more counters: in the past, I have found it helpful to see explicit packet protocol counts for the levels. The counters above would not help: if the Rx count is zero, is it because o No Hellos have been seen? o I've seen hellos, but we couldn't agree on an area or password? Further, the levels are mashed together, making it hard to debug problems where the protocol is working at one level but not the other. I could a) clarify what is being described by these counters, or b) split into two sets of counters for the levels, c) split into 4 set of counters for hello, LSP, CSNP, and PSNP, d) split into Hello and control, e) some combination of these Any comments from the list? I would vote for c) & b). - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 15 13:35:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26885 for ; Thu, 15 Feb 2001 13:35:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63047; Thu, 15 Feb 2001 11:06:02 -0800 (PST) Received: from pefw00.ivmg.net ([64.209.84.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63035 for ; Thu, 15 Feb 2001 11:05:40 -0800 (PST) Received: from pimx00.ivmg.net (pimx00.ivmg.net [192.168.0.10]) by pefw00.ivmg.net (iVMG) with ESMTP id f1FIWjh02638; Thu, 15 Feb 2001 18:32:45 GMT Received: (from serge@localhost) by pimx00.ivmg.net (iVMG) id f1FIWjs04929; Thu, 15 Feb 2001 10:32:45 -0800 From: Serge Maskalik To: Jeff Parker Cc: "'Radhika Srivatsa'" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question about a ISIS MIB variable Message-ID: <20010215103245.Q9656@ivmg.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jparker@axiowave.com on Thu, Feb 15, 2001 at 09:04:06AM -0500 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 15 Feb 2001 10:32:45 -0800 > This clearly need clarification, and perhaps modification. > I would prefer to see more counters: in the past, I have found > it helpful to see explicit packet protocol counts for the levels. > The counters above would not help: if the Rx count is zero, is it because > > o No Hellos have been seen? > o I've seen hellos, but we couldn't agree on an area or password? > > Further, the levels are mashed together, making it hard to debug > problems where the protocol is working at one level but not the other. > > I could > a) clarify what is being described by these counters, or > b) split into two sets of counters for the levels, > c) split into 4 set of counters for hello, LSP, CSNP, and PSNP, > d) split into Hello and control, > e) some combination of these > > Any comments from the list? I would vote for c) & b). > I agree, it would be useful to see counters at level and PDU type granularity. - Serge > - jeff parker > - axiowave networks > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 17 03:01:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01848 for ; Sat, 17 Feb 2001 03:01:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA71647; Sat, 17 Feb 2001 00:29:02 -0800 (PST) Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA71635 for ; Sat, 17 Feb 2001 00:28:37 -0800 (PST) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id CAA27013 for isis-wg@external.juniper.net; Sat, 17 Feb 2001 02:55:31 -0500 (EST) From: Andrew Partan To: isis-wg@spider.juniper.net Message-ID: <20010217025531.A26970@partan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Subject: [Isis-wg] Multicast NLRI Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 17 Feb 2001 02:55:31 -0500 What is the status of sticking multicast NLRI into ISIS? I know that there are at least 2 (if not more) internet drafts out there for doing this, but I don't see much discussion of the differences between them nor seeminly any movement towards just one draft. Can someone fill us in on the status of these draft(s), the differences between them, and how we get towards just one standard? Thanks, --asp@partan.com (Andrew Partan) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 17 09:23:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04379 for ; Sat, 17 Feb 2001 09:23:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75210; Sat, 17 Feb 2001 06:55:02 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75195 for ; Sat, 17 Feb 2001 06:54:58 -0800 (PST) Received: from ORANLT (oran-toshiba.cisco.com [171.69.210.2]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA15798 for ; Sat, 17 Feb 2001 06:21:52 -0800 (PST) From: "David Oran" To: Organization: Cisco Systems Message-ID: <00cc01c098ec$f785aa90$02d245ab@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C098C3.0EAFA290" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2202 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 17 Feb 2001 09:21:43 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C098C3.0EAFA290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SC6 voting on update to ISIS. =20 -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 16, 2001 5:42 AM To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; = Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; = Canada; China; Columbia; Czech Republic; Czech Republic2; Czech = Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; = Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; = Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE = 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF = (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF = (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; = Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; = ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; = Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred = Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; = Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. = Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; = SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; = UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; = UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; = Yugoslavia Subject: (jtc1sc06.144) Announcement of Document Availability ANNOUNCEMENT OF DOCUMENT AVAILABILITY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document Posted : SC6 N11851- N11852 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following documents are now available from the JTC1/SC6 web site : http://www.jtc1sc06.org ------------------------------------------ =20 ------------------------------------------ Document Number : 11851 Replaces : Document Type : Summary of Voting/Table of Replies Date Assigned : 2001-02-16 Document Title : Summary of Voting on SC 6 N 11704,=20 Text for FCD Ballot or Comment, ISO/IEC FCD 10589 =20 Due Date :=20 Pages : 2 Source : SC6 Secretariat Project Number : Status : For consideration by the Project Editor and SC 6/WG 7 Action ID : ACT ------------------------------------------- ------------------------------------------- Document Number : 11852 Replaces : Document Type : Meeting Announcement Date Assigned : 2001-02-16 Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting,=20 5-9 March 2001, Bowdon, UK Due Date : Pages : 1 Source : ASN.1 Rapporteur Project Number : Status : For information Action ID : FYI --------------------------------------------- --------------------------------------------- =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D ------=_NextPart_000_00CD_01C098C3.0EAFA290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
SC6=20 voting on update to ISIS.
 
-----Original Message-----
From: SC6 Secretariat=20 [mailto:secretariat@jtc1sc06.org]
Sent: Friday, February 16, = 2001 5:42=20 AM
To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM = Forum;=20 Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; = Canada; China;=20 Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark;=20 ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; = France1;=20 Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert = Pelsser;=20 ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; = IEEE-Robert=20 Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; = IETF=20 (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; = ISO/TC68/SC2-Philli;=20 ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 = WP 1;=20 ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; = Japan;=20 Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; = Oliver=20 Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; = Republic of=20 Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; = SC25-Walter=20 von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; = Sweden;=20 Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter = Gibbon;=20 Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; = USA-Geoff=20 Thompso; Yugoslavia
Subject: (jtc1sc06.144) Announcement of = Document=20 Availability

ANNOUNCEMENT OF DOCUMENT=20 AVAILABILITY

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Document Posted=20 : SC6 N11851- = N11852
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The=20 following documents are now available from the JTC1/SC6 web site :
http://www.jtc1sc06.org

------------------------------------------
 
----= --------------------------------------

Document=20 Number : 11851
Replaces :
Document Type : Summary of Voting/Table = of=20 Replies
Date Assigned : 2001-02-16
Document Title :  Summary = of=20 Voting on SC 6 N 11704,
Text for FCD Ballot or = Comment, ISO/IEC FCD=20 10589            =
Due=20 Date :
Pages : 2
Source : SC6 Secretariat
Project Number = :
Status :=20 For consideration by the Project Editor and SC 6/WG 7
Action ID :=20 ACT

-------------------------------------------

-----------= --------------------------------

Document=20 Number : 11852
Replaces :
Document Type : Meeting = Announcement
Date=20 Assigned : 2001-02-16
Document Title : Calling Notice from the SC = 6/WG 7=20 ASN.1 Meeting,
5-9 March 2001, Bowdon, = UK
Due Date :
Pages :=20 1
Source : ASN.1 Rapporteur
Project Number :
Status : For=20 information
Action ID :=20 FYI

---------------------------------------------

---------= ------------------------------------
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran=20 Lee
JTC1/SC6 Secretariat
Korean Standards Association
Phone: = +82 2 369=20 8308
Fax: +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
------=_NextPart_000_00CD_01C098C3.0EAFA290-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 21 06:46:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22620 for ; Wed, 21 Feb 2001 06:46:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA96990; Wed, 21 Feb 2001 04:18:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA96973 for ; Wed, 21 Feb 2001 04:17:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1LBgva21621 for ; Wed, 21 Feb 2001 03:42:57 -0800 (PST) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22146; Wed, 21 Feb 2001 06:43:51 -0500 (EST) Message-Id: <200102211143.GAA22146@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 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-diff-te-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 21 Feb 2001 06:43:51 -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 : Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-isis-diff-te-00.txt Pages : 7 Date : 20-Feb-01 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to ISIS for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt 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-diff-te-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-diff-te-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: <20010220155949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-diff-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-diff-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155949.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 21 06:51:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22763 for ; Wed, 21 Feb 2001 06:51:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA97014; Wed, 21 Feb 2001 04:19:37 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA96978 for ; Wed, 21 Feb 2001 04:17:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1LBh2a21627 for ; Wed, 21 Feb 2001 03:43:02 -0800 (PST) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22162; Wed, 21 Feb 2001 06:43:56 -0500 (EST) Message-Id: <200102211143.GAA22162@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 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 21 Feb 2001 06:43:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-00.txt Pages : 6 Date : 20-Feb-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-00.txt 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-transient-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-transient-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: <20010220155957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155957.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 21 22:30:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18802 for ; Wed, 21 Feb 2001 22:30:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA00852; Wed, 21 Feb 2001 20:02:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA00840 for ; Wed, 21 Feb 2001 20:01:34 -0800 (PST) From: Internet-Drafts@ietf.org Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f1M3Qra54411 for ; Wed, 21 Feb 2001 19:26:54 -0800 (PST) X-JNPR-Received-From: outside Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm43a94e889; Thu, 22 Feb 2001 03:20:37 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm28f3a93f068; Wed, 21 Feb 2001 12:19:32 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28219 for ietf-123-outbound.02@ietf.org; Wed, 21 Feb 2001 07:05:00 -0500 (EST) 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 GAA27930 for ; Wed, 21 Feb 2001 06:43:54 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22146; Wed, 21 Feb 2001 06:43:51 -0500 (EST) Message-Id: <200102211143.GAA22146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-diff-te-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 21 Feb 2001 06:43:51 -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 : Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-isis-diff-te-00.txt Pages : 7 Date : 20-Feb-01 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to ISIS for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt 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-diff-te-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-diff-te-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: <20010220155949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-diff-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-diff-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155949.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 24 01:34:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06869 for ; Sat, 24 Feb 2001 01:34:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA12781; Fri, 23 Feb 2001 23:06:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA10025 for ; Fri, 23 Feb 2001 10:52:08 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1NIHDa17556 for ; Fri, 23 Feb 2001 10:17:13 -0800 (PST) X-JNPR-Received-From: outside Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14353 for ; Fri, 23 Feb 2001 13:18:12 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11012 for ; Fri, 23 Feb 2001 13:18:15 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 13:18:13 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF03518160@whq-msgusr-02.pit.comms.marconi.com> From: "Lengel, Patrick" To: "'isis-wg@juniper.net'" 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 there an Ethertype value used for the IS-IS Routing protocol? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 23 Feb 2001 13:18:11 -0500 Question for the "IS-IS for IP Internets (isis)" Working Group, Is there a two byte Ethertype value used for the IS-IS Routing protocol over an Ethernet link? If so, what is it? I need to pick out all "Routed ISO" PDUs from a network card and forward them to a router. I see that RFC 2684 points out the LLC SAP value used for Routed ISO PDUs as 0xFE and that the Network Layer Protocol ID specifies the type of Routed ISO PDU that has been recieved. However, on an Ethernet link I could receive either 802.3 or Ethernet formatted PDUs. I can resolve Routed ISO traffic when packets are formatted to the 802.3 spec, however I do not know how to detect Routed ISO traffic when packets are formatted to the Ethernet spec and use a two byte Ethertype value. Any assistance in this matter would be greatly appreciated. Thank you........... Patrick Lengel ______________________________________________________________ Patrick Lengel Voice: (724)742-6780 Senior Software Engineer Fax: (724)742-6800 Marconi Communications Email: Patrick.Lengel@marconi.com 2000 FORE Drive URL: www.marconi.com Warrendale, PA 15086-7566 ______________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 24 12:46:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20951 for ; Sat, 24 Feb 2001 12:46:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA17399; Sat, 24 Feb 2001 10:18:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA17387 for ; Sat, 24 Feb 2001 10:17:37 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1OHgWa43903 for ; Sat, 24 Feb 2001 09:42:32 -0800 (PST) X-JNPR-Received-From: outside Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05034; Sat, 24 Feb 2001 09:43:36 -0800 (PST) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA03994; Sat, 24 Feb 2001 12:43:35 -0500 (EST) Message-Id: <200102241743.MAA03994@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? To: isis-wg@juniper.net, Patrick.Lengel@marconi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 25SOYgiX39Z8oD7SkdxZnw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 24 Feb 2001 12:43:35 -0500 (EST) I'd bet there was no Ethertype, and that the only way of sending them is with the globally assigned SAP, because ISO believed in the "standard" 802 encoding, and besides there wouldn't have been a reason to send things in two different envelope types. I don't know for sure, though, so anyone else feel free to contradict. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 24 13:26:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21250 for ; Sat, 24 Feb 2001 13:26:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA17611; Sat, 24 Feb 2001 10:59:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA17599 for ; Sat, 24 Feb 2001 10:58:17 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1OINCa44217 for ; Sat, 24 Feb 2001 10:23:12 -0800 (PST) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28643; Sat, 24 Feb 2001 13:23:42 -0500 (EST) Received: from sevsisters (jlearman-dsl3.cisco.com [10.83.2.140]) by dingdong.cisco.com (Mirapoint) with SMTP id ABH51451; Sat, 24 Feb 2001 13:24:16 -0500 (EST) Message-ID: <009e01c09e8e$d4604f00$8c02530a@sevsisters> From: "Jeff Learman" To: "Lengel, Patrick" , References: <4FBEA8857476D311A03300204840E1CF03518160@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 24 Feb 2001 13:23:04 -0500 Content-Transfer-Encoding: 7bit Patrick, RFC 1195 says to use packet formats defined in ISO 10589, which requires 802.3 encapsulation. Any attempt to use an Ethertype code for ISO network layer packets would have caused serious interoperability problems with existing equipment, so I don't think anyone has tried to push it. I do know of a number of implementations (mostly SONET NEs) that won't recognize IS-IS or CLNP packets if they're sent using Ethernet-format frames. Regards, Jeff ----- Original Message ----- From: Lengel, Patrick To: Sent: Friday, February 23, 2001 1:18 PM Subject: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? > Question for the "IS-IS for IP Internets (isis)" Working Group, > > Is there a two byte Ethertype value used for the IS-IS Routing protocol over > an Ethernet link? If so, what is it? > > I need to pick out all "Routed ISO" PDUs from a network card and forward > them to a router. I see that RFC 2684 points out the LLC SAP value used for > Routed ISO PDUs as 0xFE and that the Network Layer Protocol ID specifies the > type of Routed ISO PDU that has been recieved. However, on an Ethernet link > I could receive either 802.3 or Ethernet formatted PDUs. I can resolve > Routed ISO traffic when packets are formatted to the 802.3 spec, however I > do not know how to detect Routed ISO traffic when packets are formatted to > the Ethernet spec and use a two byte Ethertype value. > > Any assistance in this matter would be greatly appreciated. > > Thank you........... Patrick Lengel > > ______________________________________________________________ > Patrick Lengel Voice: (724)742-6780 > Senior Software Engineer Fax: (724)742-6800 > Marconi Communications Email: Patrick.Lengel@marconi.com > 2000 FORE Drive URL: www.marconi.com > Warrendale, PA 15086-7566 > ______________________________________________________________ > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 25 01:59:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04586 for ; Sun, 25 Feb 2001 01:59:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA20485; Sat, 24 Feb 2001 23:29:07 -0800 (PST) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA20473 for ; Sat, 24 Feb 2001 23:28:10 -0800 (PST) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2650.21) id <17AQYPP0>; Sun, 25 Feb 2001 01:51:20 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> From: "Martin, Christian" To: "IS-IS WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Interest in Supporting PTP Behavior on LAN Media in IS-IS? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 25 Feb 2001 01:51:19 -0500 Folks, I know that over the years, the idea of supporting NBMA interfaces has been tossed around the IS-IS community with little interest generated. I assume that the idea was spurred by the need to support partial-mesh, switched WANs, such as Frame Relay. The argument aginst this support was that these media could be made into PTP media through static PVCs, at the expense of address space. Recently, I have been wondering about the utility of supporting directed, PTP adjacencies over high-speed LAN interfaces, in an attempt to provide deterministic, per-adjacency metric state. Since I have no experience in IS-IS protocol development, I was hoping those who have can enlighten me on the level of difficulty required to produce such an implementation, before I embark on authoring or co-authoring a draft. Is there any interest (outside my own), in supporting per adjacency state across LAN media? Perhaps an example would help illuminate the need as I see it. Today's ISP POP architecture is often built using PTP POS trunks between all core routers in the POP. Edge/Aggregation routers are often redundnatly uplinked to multiple core routers via POS interfaces as well. In many cases, POS links may be substituted by ATM PVCs, but this case diminishes as bandwidth needs rise, and it still looks as if no vendor has any interest in building OC-48 or higher SARs. Give N core routers and M Edge/Aggregation routers, such an architecture requires N(N-1) + N(M+N) = 2N^2 + N(M-1) POS interfcaes per POP. Given the minimum required number of nodes and links needed for edge and core redundancy, M = N = 2, which results in 10 POS ports. Since many ISP POPs have N >= 3 and M >= 10, this yields a minimum 45 POS ports per POP. At OC-48/192 speeds for N-N connectivity, and OC-48/12 speeds for N-M connectivity, this results in N(N-1)* + N(N + M)* A less optimal, but much more cost effective approach would be to use 10GigE interfaces instead of OC192/48 interfaces, and GigE instead of OC-48/12 interfaces. By linking each device tigether through a pair of redundant GigE switches, the number of GigE ports on the routers reduce to 2(N + M), and the cost reduces to 2N + 2(N+M), plus 2(N+M) cost of GigE ports on the switches (which is generally an order of magnitude less than the cost of router ports of the same type when the switch density is high, utilization-wise). This obviously has significant advantages cost-wise, but there are glaring disadvantages technology-wise. In particular, link restoration mechanisms inherent in SONET are not available, as is end-to-end link management in general, thus requireing reliance upon proptocol adjacency state to detect remote link trouble. TE may be more difficult across shared LAN media as well, however, I cannot substantiate this claim from experience. In particular, though, all routers adjacent over the same subnetwork share the same metric. This subtle deficiency is exasperated when routers have different link speeds (and thus) metrics into the switch fabric. This particular deficiency renders IGP TE using metrics impossible. A potential solution to this problem would be to create Z=[N(N-1) + N(N + M)]/2 VLANs through the switch fabric, and connect the routers over /30 or /31 subnetworks. However, this causes the creation Z pseudonodes in the IS-IS domain. Given an ISP backbone consisting of N = 100 and M =200, this requires 19950 pseudonodes which has obvious drawbacks, even given the ability to support more than 255 pseudonodes as recently proposed. What would be nice would be one of two things: 1) Allow an operator to selectively turn LAN-based media into PTP links as seen by IS-IS. 2) Allow an operator to selectively define neighbors across LAN media and associate metrics to each neighbor. As I see it, both have pros and cons. 1) makes it easier on the operator, as he/she only needs to set the link type to PTP, and the rest of the configuration would be akin to real PTP interfaces. However, it requires the CLNS/IS-IS stack to be able to discover IS-IS (trivial) nodes and direct IS-IS PDUs at it and only it, which sems non-trivial (this is where I need assistance from the dvelopers). 2) makes it easier on the developers?, but harder on the operator, as now the operator has to explicitly define neighbors. Another pro, however, is that this method conserves address space, and eliminates the need to create and manage hundreds of VLANs per switch. Finally, I know of one vendor who has done this with OSPF, although the IP-ness of OSPF may or may not make this easier, particularly to those vendors with no interest in supporting a full CLNP stack. I suppose that ES-IS could be used to resolve system IDs to MAC addresses in 2), and then IIH hellos could be hacked to use the learned MAC instead of the standard multicast MAC addressed used in LAN IIHs. But, is this hard to do development-wise? Is there a workable solution to 1)? Could IS-IS be made to send IIHs on LAN media without performing DIS election? I sincerely hope I am not blowing a bunch of wind, but I am open to any and all flaming if this idea is completely baseless. If there is any interest, I'd be very willing to contribute to a draft effort. Best Regards, -chris _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 25 09:56:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09646 for ; Sun, 25 Feb 2001 09:56:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA22543; Sun, 25 Feb 2001 07:27:02 -0800 (PST) Received: from dominion.cisco.com (dominion.cisco.com [161.44.224.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA22531 for ; Sun, 25 Feb 2001 07:26:38 -0800 (PST) Received: from pots.cisco.com (mirapoint@pots.cisco.com [161.44.224.224]) by dominion.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA29209 for ; Sun, 25 Feb 2001 09:52:32 -0500 (EST) Received: from ORANLT (oran-toshiba.cisco.com [171.69.210.2]) by pots.cisco.com (Mirapoint) with ESMTP id AFH00450; Sun, 25 Feb 2001 09:52:29 -0500 (EST) From: "David Oran" To: Organization: Cisco Systems Message-ID: <000f01c09f3a$93394f20$02d245ab@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C09F10.AA634720" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [Isis-wg] FW: How can we access these documents? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 25 Feb 2001 09:52:28 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C09F10.AA634720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 23, 2001 9:09 PM To: David Oran Subject: Re: How can we access these documents? Dear Dave Oran, To download the documents from the SC6 website you need Login ID : Jtc1sc06 Password : sc06 Best wishes, Jooran Lee =============================== Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =============================== ----- Original Message ----- From: David Oran To: secretariat@jtc1sc06.org Sent: Saturday, February 24, 2001 3:48 AM Subject: How can we access these documents? We need them for the work of the ISIS working group in IETF. Any help would be greatly appreciated. Regards, Dave Oran. Area Director Routing Internet Engineering Steering Group -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Monday, February 19, 2001 6:02 AM To: David Oran Cc: micah Bartell Subject: Re: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Dave, Is there a way to actually see the SoV document. It seems to want an authorized login. Mike At 09:21 17/02/2001 -0500, you wrote: SC6 voting on update to ISIS. -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 16, 2001 5:42 AM To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; Yugoslavia Subject: (jtc1sc06.144) Announcement of Document Availability ANNOUNCEMENT OF DOCUMENT AVAILABILITY ========================================= Document Posted : SC6 N11851- N11852 ========================================= The following documents are now available from the JTC1/SC6 web site : http://www.jtc1sc06.org ------------------------------------------ ------------------------------------------ Document Number : 11851 Replaces : Document Type : Summary of Voting/Table of Replies Date Assigned : 2001-02-16 Document Title : Summary of Voting on SC 6 N 11704, Text for FCD Ballot or Comment, ISO/IEC FCD 10589 Due Date : Pages : 2 Source : SC6 Secretariat Project Number : Status : For consideration by the Project Editor and SC 6/WG 7 Action ID : ACT ------------------------------------------- ------------------------------------------- Document Number : 11852 Replaces : Document Type : Meeting Announcement Date Assigned : 2001-02-16 Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting, 5-9 March 2001, Bowdon, UK Due Date : Pages : 1 Source : ASN.1 Rapporteur Project Number : Status : For information Action ID : FYI --------------------------------------------- --------------------------------------------- =============================== Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =============================== ------=_NextPart_000_0010_01C09F10.AA634720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: SC6 Secretariat=20 [mailto:secretariat@jtc1sc06.org]
Sent: Friday, February 23, = 2001=20 9:09 PM
To: David Oran
Subject: Re: How can we = access these=20 documents?

Dear Dave Oran,
 
To download the documents = from the SC6=20 website
you need
 
Login ID : = Jtc1sc06
Password : sc06
 
Best wishes,
Jooran Lee
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran=20 Lee
JTC1/SC6 Secretariat
Korean Standards Association
Phone: = +82 2 369=20 8308
Fax: +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
----- Original = Message -----
From:=20 David = Oran
Sent: = Saturday, February 24, 2001 3:48=20 AM
Subject: How can we access these=20 documents?

We=20 need them for the work of the ISIS working group in = IETF.
 
Any=20 help would be greatly appreciated.
 
Regards,
 
Dave=20 Oran.
Area=20 Director
Routing
Internet Engineering Steering Group
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent:= =20 Monday, February 19, 2001 6:02 AM
To: David = Oran
Cc: micah=20 Bartell
Subject: Re: [Isis-wg] FW: (jtc1sc06.144) = Announcement of=20 Document=20 = Availability

Dave,
    =     Is=20 there a way to actually see the SoV document. It seems to want an = authorized=20 = login.

                Mike
At=20 09:21 17/02/2001 -0500, you wrote:
SC6=20 voting on update to ISIS.
 
-----Original Message-----
From: SC6 Secretariat = [mailto:secretariat@jtc1sc06.org]
Sent:=20 Friday, February 16, 2001 5:42 AM
To: Argentina; ASN.1-J.=20 Larmouth; ASTM-Teresa J Cen; ATM Forum; Australia; Austria; = Austria2; B.=20 Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech = Republic;=20 Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc;=20 ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; = Greece;=20 Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse=20 Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert=20 Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF = (Routeing)2; IETF=20 (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland;=20 ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T = SG=20 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack=20 Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; = New=20 Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; = Poland1;=20 Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; = Russian=20 Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; = SC29-Yukiko=20 Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The=20 Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; = Ukraine1;=20 Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff = Thompso;=20 Yugoslavia
Subject: (jtc1sc06.144) Announcement of = Document=20 Availability

ANNOUNCEMENT OF DOCUMENT=20 = AVAILABILITY

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Document=20 Posted : SC6 N11851-=20 = N11852
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The = following=20 documents are now available from the JTC1/SC6 web site :
http://www.jtc1sc06.org

-----= -------------------------------------
 
----------------------= --------------------

Document=20 Number : 11851
Replaces :
Document Type : Summary of = Voting/Table of=20 Replies
Date Assigned : 2001-02-16
Document Title :  = Summary of=20 Voting on SC 6 N 11704,
Text for FCD Ballot or = Comment,=20 ISO/IEC FCD=20 = 10589           =20
Due Date :
Pages : 2
Source : SC6 Secretariat
Project = Number=20 :
Status : For consideration by the Project Editor and SC 6/WG=20 7
Action ID :=20 = ACT

-------------------------------------------

-----------= --------------------------------

Document=20 Number : 11852
Replaces :
Document Type : Meeting = Announcement
Date=20 Assigned : 2001-02-16
Document Title : Calling Notice from the SC = 6/WG 7=20 ASN.1 Meeting,
5-9 March 2001, Bowdon, = UK
Due=20 Date :
Pages : 1
Source : ASN.1 Rapporteur
Project Number=20 :
Status : For information
Action ID :=20 = FYI

---------------------------------------------

---------= ------------------------------------
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran Lee
JTC1/SC6=20 Secretariat
Korean Standards Association
Phone: +82 2 369 = 8308
Fax:=20 +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------=_NextPart_000_0010_01C09F10.AA634720-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 14:03:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24099 for ; Tue, 27 Feb 2001 14:03:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA34805; Tue, 27 Feb 2001 11:34:03 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA34793 for ; Tue, 27 Feb 2001 11:33:24 -0800 (PST) Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA09609; Tue, 27 Feb 2001 10:59:01 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> To: "Martin, Christian" From: Bora Akyol Subject: Re: [Isis-wg] Interest in Supporting PTP Behavior on LAN Media in IS-IS? Cc: "IS-IS WG (E-mail)" 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 10:57:36 -0800 What's wrong with using PPP over Ethernet to achieve what you want without changing anything else? This is why PPPoE was invented. Bora At 1:51 AM -0500 2/25/01, Martin, Christian wrote: >Folks, > >I know that over the years, the idea of supporting NBMA interfaces has been >tossed around the IS-IS community with little interest generated. I assume >that the idea was spurred by the need to support partial-mesh, switched >WANs, such as Frame Relay. The argument aginst this support was that these >media could be made into PTP media through static PVCs, at the expense of >address space. Recently, I have been wondering about the utility of >supporting directed, PTP adjacencies over high-speed LAN interfaces, in an >attempt to provide deterministic, per-adjacency metric state. Since I have >no experience in IS-IS protocol development, I was hoping those who have can >enlighten me on the level of difficulty required to produce such an >implementation, before I embark on authoring or co-authoring a draft. Is >there any interest (outside my own), in supporting per adjacency state >across LAN media? Perhaps an example would help illuminate the need as I >see it. > > >Today's ISP POP architecture is often built using PTP POS trunks between all >core routers in the POP. Edge/Aggregation routers are often redundnatly >uplinked to multiple core routers via POS interfaces as well. In many >cases, POS links may be substituted by ATM PVCs, but this case diminishes as >bandwidth needs rise, and it still looks as if no vendor has any interest in >building OC-48 or higher SARs. Give N core routers and M Edge/Aggregation >routers, such an architecture requires N(N-1) + N(M+N) = 2N^2 + N(M-1) POS >interfcaes per POP. Given the minimum required number of nodes and links >needed for edge and core redundancy, M = N = 2, which results in 10 POS >ports. Since many ISP POPs have N >= 3 and M >= 10, this yields a minimum >45 POS ports per POP. At OC-48/192 speeds for N-N connectivity, and >OC-48/12 speeds for N-M connectivity, this results in N(N-1)*cost> + N(N + M)*routers. > > >A less optimal, but much more cost effective approach would be to use 10GigE >interfaces instead of OC192/48 interfaces, and GigE instead of OC-48/12 >interfaces. By linking each device tigether through a pair of redundant >GigE switches, the number of GigE ports on the routers reduce to 2(N + M), >and the cost reduces to 2N + 2(N+M), >plus 2(N+M) cost of GigE ports on the switches (which is generally an order >of magnitude less than the cost of router ports of the same type when the >switch density is high, utilization-wise). This obviously has significant >advantages cost-wise, but there are glaring disadvantages technology-wise. >In particular, link restoration mechanisms inherent in SONET are not >available, as is end-to-end link management in general, thus requireing >reliance upon proptocol adjacency state to detect remote link trouble. TE >may be more difficult across shared LAN media as well, however, I cannot >substantiate this claim from experience. In particular, though, all routers >adjacent over the same subnetwork share the same metric. This subtle >deficiency is exasperated when routers have different link speeds (and thus) >metrics into the switch fabric. This particular deficiency renders IGP TE >using metrics impossible. > >A potential solution to this problem would be to create Z=[N(N-1) + N(N + >M)]/2 VLANs through the switch fabric, and connect the routers over /30 or >/31 subnetworks. However, this causes the creation Z pseudonodes in the >IS-IS domain. Given an ISP backbone consisting of N = 100 and M =200, this >requires 19950 pseudonodes which has obvious drawbacks, even given the >ability to support more than 255 pseudonodes as recently proposed. > >What would be nice would be one of two things: > >1) Allow an operator to selectively turn LAN-based media into PTP links as >seen by IS-IS. >2) Allow an operator to selectively define neighbors across LAN media and >associate metrics to each neighbor. > >As I see it, both have pros and cons. 1) makes it easier on the operator, >as he/she only needs to set the link type to PTP, and the rest of the >configuration would be akin to real PTP interfaces. However, it requires >the CLNS/IS-IS stack to be able to discover IS-IS (trivial) nodes and direct >IS-IS PDUs at it and only it, which sems non-trivial (this is where I need >assistance from the dvelopers). 2) makes it easier on the developers?, but >harder on the operator, as now the operator has to explicitly define >neighbors. Another pro, however, is that this method conserves address >space, and eliminates the need to create and manage hundreds of VLANs per >switch. Finally, I know of one vendor who has done this with OSPF, although >the IP-ness of OSPF may or may not make this easier, particularly to those >vendors with no interest in supporting a full CLNP stack. > >I suppose that ES-IS could be used to resolve system IDs to MAC addresses in >2), and then IIH hellos could be hacked to use the learned MAC instead of >the standard multicast MAC addressed used in LAN IIHs. But, is this hard to >do development-wise? Is there a workable solution to 1)? Could IS-IS be >made to send IIHs on LAN media without performing DIS election? > >I sincerely hope I am not blowing a bunch of wind, but I am open to any and >all flaming if this idea is completely baseless. If there is any interest, >I'd be very willing to contribute to a draft effort. > >Best Regards, >-chris >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 17:42:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03715 for ; Tue, 27 Feb 2001 17:42:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA35689; Tue, 27 Feb 2001 15:13:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA35677 for ; Tue, 27 Feb 2001 15:12:47 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1RMbAa38012 for ; Tue, 27 Feb 2001 14:37:10 -0800 (PST) X-JNPR-Received-From: outside Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06444 for ; Tue, 27 Feb 2001 14:38:24 -0800 (PST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA20025 for ; Tue, 27 Feb 2001 17:38:23 -0500 (EST) Message-Id: <200102272238.RAA20025@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ya+on1lDtXBL4gDyHfVFcw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 17:38:22 -0500 (EST) I sent minor typos, etc., to the authors, but we had an interesting discussion about the following idea, which is now sufficiently baked to mention to the list. An extension to the problem of quickly detecting a neighbor is down, while perhaps avoiding false declarations of down if the hello process can't be immediately scheduled to sub-second timing... Suppose receipt of data on an adjacency reset the hello timer? Various thoughts on that: You might even avoid sending as many hellos, if you know that you've recently sent data to that adjacency On LANs, where the hello is multicast but data is unicast, the data to the DIS would be the data that counted, not data to some other adjacency on that LAN To allow other information in the Hello to change (area address, etc.) the sender could be required to occasionally send hellos. So, for instance, you'd want to detect him down very very quickly (so perhaps the expiration for that might be subsecond, with either hellos or data resetting that timer), but for changing the information in a hello, this would not need to be so timely...it would be OK to be tens of seconds, so the sender could postpone sending hellos for awhile, but not indefinitely, if he's sending traffic. If the info changed at a router, that router could instantly issue a hello with the new information, but since that might get lost, it's still necessary to occasionally refresh the info in the hello. So to implement this: need an option in the Hello to say "I'm cool with receipt of data messages instead of Hellos". If your neighbor says that, then you don't have to send hellos in a timely way if you're sending traffic. The receiver should reset timer on receipt of either Hello or data. The transmitter still would send Hellos periodically, but not with sub-second requirement if there's traffic. Instead, if the Holding Timer you tell your neighbor is less than, say, 5 seconds, and your neighbor is willing to accept data in lieu of Hellos, then you can postpone sending Hellos, but not longer than, say, 30 seconds. I think 5 and 30 could be architectural constants rather than yet more parameters. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 18:14:20 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04548 for ; Tue, 27 Feb 2001 18:14:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA35860; Tue, 27 Feb 2001 15:45:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA35823 for ; Tue, 27 Feb 2001 15:44:17 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1RN8ea39543 for ; Tue, 27 Feb 2001 15:08:40 -0800 (PST) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA02255; Tue, 27 Feb 2001 18:09:19 -0500 (EST) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-116.cisco.com [64.102.83.116]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABI02592; Tue, 27 Feb 2001 18:09:53 -0500 (EST) Message-Id: <4.3.2.7.2.20010227175640.0337fe68@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Radia Perlman - Boston Center for Networking From: Jeff Learman Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Cc: isis-wg@juniper.net In-Reply-To: <200102272238.RAA20025@bcn.East.Sun.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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 18:07:40 -0500 Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 18:30:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04929 for ; Tue, 27 Feb 2001 18:30:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA35968; Tue, 27 Feb 2001 16:01:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA35956 for ; Tue, 27 Feb 2001 16:00:30 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1RNOra40147 for ; Tue, 27 Feb 2001 15:24:53 -0800 (PST) X-JNPR-Received-From: outside Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17305; Tue, 27 Feb 2001 15:26:05 -0800 (PST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA20260; Tue, 27 Feb 2001 18:26:03 -0500 (EST) Message-Id: <200102272326.SAA20260@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt To: Radia.Perlman@east.sun.com, jlearman@cisco.com Cc: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Es5/WdGPyzDkEWfIBuXoJA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) I think what you said is what I mean. You would have to be aware of when you last sent something on each such adjacency to know whether you can postpone a hello on that adjacency. If you don't like that, would this be easier on the implementation? Having a nonzero queue of stuff to that adjacency would be sufficient information that you don't need to send a Hello on that adjacency. So, for instance, if the queue is empty, send a Hello...what harm is there since you're not doing anything anyway. But if the queue is nonempty, then you can skip actually transmitting that Hello. Radia X-Sender: jlearman@dingdong.cisco.com To: Radia Perlman - Boston Center for Networking From: Jeff Learman Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Cc: isis-wg@juniper.net Mime-Version: 1.0 Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 18:45:41 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05222 for ; Tue, 27 Feb 2001 18:45:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA36080; Tue, 27 Feb 2001 16:16:03 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA36068 for ; Tue, 27 Feb 2001 16:15:06 -0800 (PST) Received: from ORANLT ([10.21.54.12]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA29049 for ; Tue, 27 Feb 2001 15:40:44 -0800 (PST) From: "David R. Oran" To: Subject: FW: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Organization: Cisco Systems Message-ID: <001101c0a116$b3450010$5cfeff0a@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_01C0A0EC.CA6EF810" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 18:40:32 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Micah Bartell [mailto:mbartell@cisco.com] Sent: Thursday, February 22, 2001 1:51 PM To: David Oran Subject: Re: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability David, Here is the actual results of the vote. They do not include the US vote with comments. The US voted NO on the document with significant comments. So what is actually happening with it is still unknown. If it did get voted in, that would be a *bad thing*, in which we will need to determine how to get the US and French comments reviewed and integrated. /mpb At 09:21 AM 2/17/2001 -0500, you wrote: >SC6 voting on update to ISIS. > >-----Original Message----- >From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] >Sent: Friday, February 16, 2001 5:42 AM >To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; >Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; Yugoslavia >Subject: (jtc1sc06.144) Announcement of Document Availability > >ANNOUNCEMENT OF DOCUMENT AVAILABILITY > >========================================= >Document Posted : SC6 N11851- N11852 >========================================= > >The following documents are now available from the JTC1/SC6 web site : >http://www.jtc1sc06.org > >------------------------------------------ > >------------------------------------------ > >Document Number : 11851 >Replaces : >Document Type : Summary of Voting/Table of Replies >Date Assigned : 2001-02-16 >Document Title : Summary of Voting on SC 6 N 11704, >Text for FCD Ballot or Comment, ISO/IEC FCD 10589 >Due Date : >Pages : 2 >Source : SC6 Secretariat >Project Number : >Status : For consideration by the Project Editor and SC 6/WG 7 >Action ID : ACT > >------------------------------------------- > >------------------------------------------- > >Document Number : 11852 >Replaces : >Document Type : Meeting Announcement >Date Assigned : 2001-02-16 >Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting, >5-9 March 2001, Bowdon, UK >Due Date : >Pages : 1 >Source : ASN.1 Rapporteur >Project Number : >Status : For information >Action ID : FYI > >--------------------------------------------- > >--------------------------------------------- > >=============================== >Ms. Jooran Lee >JTC1/SC6 Secretariat >Korean Standards Association >Phone: +82 2 369 8308 >Fax: +82 2 369 8349 >Email: secretariat@jtc1sc06.org >http://www.jtc1sc06.org >=============================== ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: application/msword; name="N11851.doc" Content-Disposition: attachment; filename="N11851.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAEgAAAAAAAAAA EAAAEwAAAAEAAAD+////AAAAABEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAgAAAAAAAAwAAqw0AAF8gAAAAAAAAAAAAAAAAAAAAAAAAqwoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAADoDAAAAHAAAOgMAADofAAAAAAAAOh8A AAAAAAA6HwAAAAAAADofAAAAAAAAOh8AABQAAABOHwAAAAAAAE4fAAAAAAAATh8AAAAAAABOHwAA AAAAAE4fAAAAAAAATh8AAAoAAABYHwAAIgAAAE4fAAAAAAAAfB8AAEEAAAB6HwAAAAAAAHofAAAA AAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAIA AAB8HwAAAAAAAHwfAAAAAAAAfB8AAAAAAAB8HwAAAAAAAHwfAAAAAAAAfB8AAAAAAAC9HwAAWAAA ABUgAABKAAAAfB8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOh8AAAAAAAB6HwAAAAAAAAAACAAJAAEA BQB6HwAAAAAAAHofAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHofAAAAAAAAeh8AAAAAAAB8HwAAAAAA AHofAAAAAAAAOh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHofAAAAAAAA eh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAOh8AAAAAAAB6 HwAAAAAAAHofAAAAAAAAAAAAAAAAAACA/RP5AZjAAU4fAAAAAAAATh8AAAAAAAA6HwAAAAAAADof AAAAAAAAOh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANVGVsZWNvbW11bmljYXRpb25zIGFuZCBJbmZvcm1h dGlvbiBFeGNoYW5nZSBCZXR3ZWVuIFN5c3RlbXMNDQlJU08vSUVDIEpUQyAxL1NDIDA2IE4xMTg1 MQ0NCURhdGU6CTIwMDEtMDItMTYNDQlSZXBsYWNlczoNDQlEb2N1bWVudCBUeXBlOglTdW1tYXJ5 IG9mIFZvdGluZy9UYWJsZSBvZiBSZXBsaWVzDQ0JRG9jdW1lbnQgVGl0bGU6CVN1bW1hcnkgb2Yg Vm90aW5nIG9uIFNDIDYgTiAxMTcwNCwgVGV4dCBmb3IgRkNEIEJhbGxvdCBvciBDb21tZW50LCBJ U08vSUVDIEZDRCAxMDU4OSAgICAgICAgICAgIA0NCURvY3VtZW50IFNvdXJjZToJU0MgNiBTZWNy ZXRhcmlhdA0NCVByb2plY3QgTnVtYmVyOg0NCURvY3VtZW50IFN0YXR1czoJRm9yIGNvbnNpZGVy YXRpb24gYnkgdGhlIFByb2plY3QgRWRpdG9yIGFuZCBTQyA2L1dHIDcNDQlBY3Rpb24gSUQ6CUFD VA0NCUR1ZSBEYXRlOg0NCU5vLiBvZiBQYWdlczoJMg0NDQlTZWNyZXRhcmlhdCwgSVNPL0lFQyBK VEMgMS9TQzYsIE1zLiBKb29yYW4gTGVlLCBLU0EgKG9uIGJlaGFsZiBvZiBLQVRTKSwgMTMtMzEg WW9pZG8tZG9uZywgWW91bmdkZXVuZ3BvLWd1LCBTZW91bCwgUmVwdWJsaWMgb2YgS29yZWE7IFRl bGVwaG9uZTogIDgyIDIgMzY5IDgzMDg7IEZhY3NpbWlsZTogIDgyIDIgMzY5IDgzNDk7IEVtYWls OiAgc2VjcmV0YXJpYXRAanRjMXNjMDYub3JnDQ0MU3VtbWFyeSBvZiBWb3Rpbmcgb24gU0MgNiBO IDExNzA0IChGQ0QxMDU4OSkNDQ1OYXRpb25hbCBCb2R5DQdBcHByb3ZlB0Rpc2FwcHJvdmUHQWJz dGFpbgdDb21tZW50cwcHQXVzdHJpYQcHBwcHB0JlbGdpdW0HBwcHBwdCcmF6aWwHBwcHBwdDYW5h ZGEHBwcHBwdDaGluYQdYBwcHBwdDemVjaCBSZXB1YmxpYwdYBwcHBwdEZW5tYXJrBwcHWA0oTGFj ayBvZiBFeHBlcnRpc2UpBwcHRmlubGFuZAcHBwcHB0ZyYW5jZQcHWAcHU2VlIEF0dGFjaGVkBwdH ZXJtYW55BwcHWA0oTGFjayBvZiBFeHBlcnRpc2UpBwcHR3JlZWNlBwcHBwcHSmFwYW4HWAcHBwcH UmVwdWJsaWMgb2YgS29yZWEHWAcHBwcHVGhlIE5ldGhlcmxhbmRzBwcHBwcHUnVzc2lhbiBGZWRl cmF0aW9uBwcHBwcHU3dpdHplcmxhbmQHBwdYBwcHVWtyYWluZQcHBwcHB1VuaXRlZCBLaW5nZG9t B1gHBwcHB1VTQQcHBwcHBw0NRnJhbmNlDV9YXyAgCURJU0FQUFJPVkFMIE9GIFRIRSBEUkFGVCBG T1IgUkVBU09OUyBCRUxPVyANDV9YXyAgQWNjZXB0YW5jZSBvZiB0aGVzZSByZWFzb25zIGFuZCBh cHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZSB0ZXh0IHdpbGwgY2hhbmdlIG91ciB2b3RlIHRvIGFw cHJvdmFsDQ1GcmVuY2ggQ29tbWVudHMgb24gSVNPL0lFQyBGQ0QgMTA1ODkNDQ1EUjAzNQ0NRFIw MzUgd2FzIHN1Ym1pdHRlZCBhZ2FpbnN0IHRoZSBmaXJzdCBlZGl0aW9uIG9mIElTTyAxMDU4OS4N DVRoZSBkZWZlY3QgaXMgcmVsYXRlZCB0byB0aGUgZm9yd2FyZGluZyBvZiBlbmNhcHN1bGF0ZWQg TlBEVSBvdmVyIGEgdmlydHVhbCBMMSBwYXRoLiBBIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRo aXMgaXNzdWUgY2FuIGJlIGZvdW5kIGluIGRvY3VtZW50IFNJRi0wMTgtMTk5OCwgcDY3LTcwLiBB cyBhIHN1bW1hcnksIHRoZSBjdXJyZW50IElTTyAxMDU4OSBlZGl0aW9uIGFsbG93cyB0d28gUERJ UyB0byBlc3RhYmxpc2ggYSB2aXJ0dWFsIGxpbmsgYmV0d2VlbiB0aGVtLCBpbiBvcmRlciB0byBy ZXBhaXIgYSBzcGxpdCBhcmVhLCB3aGlsZSB0aGV5IGNhbiBub3QgZXhjaGFuZ2UgZW5jYXBzdWxh dGVkIE5QRFVzIGFjcm9zcyB0aGUgbGV2ZWwgMiBzdWJkb21haW4uDQ1BIHNvbHV0aW9uIHRvIHRo aXMgZGVmZWN0IHJlcG9ydCB3YXMgcHJvcG9zZWQgaW4gZG9jdW1lbnQgNk4gMTA4MDEgKERDT1Ig NikuIFRoZSBwcm9wb3NlZCB0ZXh0IHdhcyBwYXJ0IG9mIHRoZSBwcmV2aW91cyBkcmFmdCBvZiB0 aGUgc2Vjb25kIGVkaXRpb24gb2YgSVNPIDEwNTg5ICh0aGlzIGRyYWZ0IHdhcyByZWplY3RlZCBz b21lIHRpbWUgYWdvKS4NRnJhbmNlIHByb3Bvc2VzIHRvIGludGVncmF0ZSB0aGlzIHRleHQgaW4g dGhlIGN1cnJlbnQgZHJhZnQgb2YgdGhlIHNlY29uZCBlZGl0aW9uIG9mIElTTyAxMDU4OS4NDUNv bXB1dGF0aW9uIG9mIGFyZWEgYWRkcmVzc2VzDQ1TSUYgZG9jdW1lbnQgU0lGLUFSLTk5MDUtMDU2 IGlkZW50aWZpZXMgYW4gaXNzdWUgdGhhdCBvY2N1cnMgYWZ0ZXIgYW4gYXJlYSBoYXMgc3BsaXQ6 IHRoZSBjdXJyZW50IGVkaXRpb24gb2YgSVNPIDEwNTg5IHN0YXRlcyB0aGF0IHRoZSBzZXQgb2Yg YXJlYSBhZGRyZXNzZXMgZm9yIGFuIGFyZWEgaXMgY29tcHV0ZWQgYmFzZWQgb24gYWRkcmVzc2Vz IGFkdmVydGlzZWQgYnkgYWxsIGxldmVsIDEgTFNQcyBmb3VuZCBpbiB0aGUgbG9jYWwgTFNQIGRh dGFiYXNlLiBIb3dldmVyLCBhZnRlciBhbiBhcmVhIGhhcyBzcGxpdCwgTDEgTFNQcyBvcmlnaW5h dGluZyBmcm9tIElTcyB0aGF0IGFyZSBubyBsb25nZXIgcmVhY2hhYmxlIHZpYSBMMSByb3V0aW5n IChhbmQgdGhhdCByZW1haW4gaW4gdGhlIGxvY2FsIGRhdGFiYXNlIHVudGlsIHRoZXkgcmVhY2gg TWF4QWdlKSwgc2hvdWxkIG5vdCBiZSB1c2VkIGZvciBhcmVhIGFkZHJlc3NlcyBjb21wdXRhdGlv bi4NDUZyYW5jZSBwcm9wb3NlcyB0byBpbnRlZ3JhdGUgdGhlIHRleHQgcHJvcG9zZWQgaW4gdGhp cyBTSUYgZG9jdW1lbnQgaW50byB0aGUgY3VycmVudCBkcmFmdCBvZiB0aGUgc2Vjb25kIGVkaXRp b24gb2YgSVNPIDEwNTg5Lg0NDS4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AoQEApNAv peA9pggHpwgHqKAFqaAFqgAAhdT/AgAAAAABgAAAAQBoAXgA/wEAAAAAAwAAAAEAaAF4AP8BAAgA AAMAAAABAGgBeAD/AQAIAAABAAAAAQBoAXgA/wEACAAAAYAAAAEAsAF4AP8BAAgAAAMAAAABAGgB eAD/AQAIAAADAAAAAQBoAXgA/wEACAAAAQAAAAEAaAF4AP8BAAgAAAEAAAABAGgBeAAAAAAAIF8/ Pz9fPz8/PygpKCkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAEDAAA9 AwAAPwMAAFoDAABcAwAAYQMAAGIDAABtAwAAbwMAAHoDAAB7AwAAiQMAAIoDAACuAwAArwMAAL4D AAC/AwAAIAQAACIEAAAyBAAAMwQAAEQEAABGBAAAVgQAAFgEAABoBAAAaQQAAJ8EAAChBAAAqwQA AKwEAACwBAAAsgQAALwEAAC+BAAAywQAAM0EAADOBAAA0QQAAK4FAADdBQAA3wUAABMGAABsBwAA cwcAAKQHAACmBwAACwgAADIIAAA0CAAAOggAADsIAAB3CAAA9gkAAMAKAAAhCwAAPwsAAKkNAACr DQAA8A4AAPz3APIA9wDwAPcA9wDwAPcA8AD3APAA9wD3APAA9wDwAPcA9wDwAO787Ons5QDj8ODe AN4A3gDeAN4A3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdQEAA2MWAAVVgWMcAANdAAAHVYFeAWMc AAVVgWMYAANjGAADYxIAA10CAAhVgV0CAGMcAAAIVYFdAgBjGAAABVWBYyAAADwAAwAAAQMAAD0D AAA+AwAAWgMAAFsDAABtAwAAbgMAAHkDAAB6AwAArQMAAK4DAAAgBAAAIQQAAEQEAABFBAAAVgQA AFcEAACfBAAAoAQAALAEAACxBAAAvAQAAL0EAADOBAAAzwQAANAEAACuBQAArwUAAN0FAADeBQAA 3wUAAO0FAADuBQAA9gUAAAEGAAAJBgAAEgYAAP0AAAAAAAD3AAAAAAAA9QAAAAAAAPcAAAAAAAD3 AAAAAAAA7gAAAAAAAPUAAAAAAAD3AAAAAAAA9wAAAAAAAO4AAAAAAADuAAAAAAAA5AAAAAAAAPUA AAAAAADuAAAAAAAA9QAAAAAAAPcAAAAAAAD1AAAAAAAA5AAAAAAAAOQAAAAAAADuAAAAAAAA9QAA AAAAAPcAAAAAAAD1AAAAAAAA7gAAAAAAAPUAAAAAAAD1AAAAAAAA3gAAAAAAAP0AAAAAAAD9AAAA AAAA9QAAAAAAAPUAAAAAAADaAAAAAAAA2gAAAAAAANoAAAAAAADaAAAAAAAA2gAAAAAAANoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAABQEYAQAFAAAPBQABkBUBAAAJAAARIA0T4PIP CAAC4AMgDQAAAAYAAA8IAALgAyANAAAAAQAAAAUAAA8FAAHgAwAAAAIAAAUBJRIGAAATBgAAGwYA ABwGAAAdBgAAHgYAAB8GAAAgBgAAKAYAACkGAAAqBgAAKwYAACwGAAAtBgAANAYAADUGAAA2BgAA NwYAADgGAAA5BgAAQAYAAEEGAABCBgAAQwYAAEQGAABFBgAASwYAAE0GAABOBgAATwYAAFAGAABR BgAAYAYAAGIGAABjBgAAZAYAAGUGAABmBgAAbgYAAG8GAABwBgAA6gAAAAAAAOcAAAAAAADjAAAA AAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAA AADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAA AOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA 4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADj AAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAAAAAAAAAAAAAAADAAAFARgBAAIAABgB ABUAABgBGQG4bAC99AG7CQAJAAkACQAJAAkAvg4ABZT/+AdqDVUUQBsrIgAocAYAAHIGAACGBgAA hwYAAIgGAACQBgAAkQYAAJIGAACTBgAAlAYAAJUGAACcBgAAnQYAAJ8GAACgBgAArQYAAK4GAAC2 BgAAtwYAALgGAAC6BgAAzgYAAM8GAADQBgAA1wYAANgGAADZBgAA2gYAANsGAADcBgAA4gYAAOQG AADlBgAA5gYAAOcGAADoBgAA+gYAAPwGAAD9BgAA/gYAAP8GAAD8AAAAAAAA/AAAAAAAAPwAAAAA AADmAAAAAAAA4wAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAADmAAAAAAAA4wAAAAAA APwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAADmAAAAAAAA4wAAAAAAAPwAAAAAAAD8AAAAAAAA /AAAAAAAAPwAAAAAAAD8AAAAAAAA5gAAAAAAAOMAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8 AAAAAAAA5gAAAAAAAOMAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA5gAAAAAAAOMA AAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAIAABgBABUAABgBGQG4 bAC99AG7CQAJAAkACQAJAAkAvg4ABZT/+AdqDVUUQBsrIgAAAwAABQEYASj/BgAAAAcAABAHAAAR BwAAEgcAABMHAAAUBwAAFQcAACgHAAApBwAAKgcAACsHAAAsBwAALQcAADkHAAA6BwAAOwcAAD0H AAA+BwAAPwcAAEcHAABIBwAASQcAAEoHAABLBwAATAcAAFsHAABdBwAAXgcAAF8HAABgBwAAYQcA AGUHAABmBwAAZwcAAGgHAABpBwAAagcAAGsHAABsBwAAcwcAAOoAAAAAAADnAAAAAAAA4wAAAAAA AOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA 4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADn AAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMA AAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAA AAAAAOoAAAAAAADhAAAAAAAA4QAAAAAAAOEAAAAAAAAAAAAAAAABAAAAAwAABQEYAQACAAAYAQAV AAAYARkBuGwAvfQBuwkACQAJAAkACQAJAL4OAAWU//gHag1VFEAbKyIAKHMHAAClBwAApgcAAAwI AAANCAAAMggAADMIAAA0CAAAOggAADsIAAB3CAAAeAgAAPUJAAD2CQAAwAoAACALAAAhCwAAPwsA AEALAAAnDQAAKA0AAKcNAACoDQAAqQ0AAKsNAAD+AAAAAAAA/gAAAAAAAPsAAAAAAAD4AAAAAAAA +AAAAAAAAPsAAAAAAAD7AAAAAAAA9QAAAAAAAPsAAAAAAADzAAAAAAAA+wAAAAAAAPsAAAAAAAD7 AAAAAAAA8wAAAAAAAPsAAAAAAAD7AAAAAAAA8QAAAAAAAPsAAAAAAAD7AAAAAAAA+wAAAAAAAPsA AAAAAAD7AAAAAAAA7wAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AwAAEdACAAABAAAAAQEAAAERAAACAQAFAwACAAAFAQACAAAFAwABGgAYDgAbAAgAAQBLAA8AAAAA ABoAAEDx/wIAGgAGTm9ybWFsAAIAAAADAGEJBAAiAAFAAQACACIACUhlYWRpbmcgMQAABAABAAgB BQBeAWMcAAAiAAJAAQACACIACUhlYWRpbmcgMgAABAACAAgBBQBVgWMWAAAkAANAAQACACQACUhl YWRpbmcgMwAABAADAAgBBwBVgV4BYxwAACIABEABAAIAIgAJSGVhZGluZyA0AAAEAAQACAEFAFWB YxgAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAAAAAA ADQAPkABAAIANAAFVGl0bGUAABoADwAFARVIAxbgAQ8OAAQaA6cENAbBBwAAAAAFAFWBYyQAADoA /k8BAAIBOgAGYnVsbGV0ACUAEAAFAxGABBNQ/hQ5/wAAFXgADxEABRoDgASnBDQGwQcAAAAAAAAA AB4AQkABABIBHgAJQm9keSBUZXh0AAACABEAAwBjFgAAKAD+TwEAIgEoAAtBU04uMSBDb250LgAA BwASAAUDEaAFAAUAVYFjEgAAKgD+TwEAMgEqAAZOb3RlIDMAEQATAAUDBwERwgUUOf8AABU8AAAD AGMSAAAwAP5PIQACADAACkhlYWRpbmcgMkEAFwAUAAUDFTkBDw4ABBoDpwQ0BsEHAAAAAAAAADYA /k8BAFIBNgAHTGV2ZWwgMwAAIAAVAAUDFYgADxcAB9ACGANgA/ADpwQ0BsEHAAAAAAAAAAAANAD+ TwEAYgE0AAdMZXZlbCA0AAAaABYABQMVeAAPEQAFGAOEA6cENAbBBwAAAAAAAwBhCQgAOgD+TwEA cgE6AAdMZXZlbCA1AAAgABcABQMR8AMTEPwVeAAPEQAFGgPwA6cENAbBBwAAAAAAAwBhCQgANgAe QAEAggE2AA9Bbm5vdGF0aW9uIFRleHQAABcAGAAFAxWIAA8OAAQaA6cENAbBBwAAAAAAAAAgAP5P AQCSASAAC0JvZHkgVGV4dCAyAAAFABkAEdACAAAAJgD+TwEAogEmAAtCb2R5IFRleHQgMgAACAAa ABHQAhMw/QMAXQIAAAAAAACrCgAAAwAADgAAAQD/////AAMAAPAOAAAIAAADAAASBgAAcAYAAP8G AABzBwAAqw0AAAkACgALAAwADQD/QEEAFRKQAQAAVGltZXMgTmV3IFJvbWFuAAwQkAECAFN5bWJv bAALIpABAABBcmlhbAAPApABAgBXaW5nZGluZ3MAIgAEAAAAgBgA8NACAABoAQAAAACZhFKm04RS pl1dMSYLACEAAACLAQAAzAgAAAEABAAAAAQAgxASAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAAAA APAQAEoAAAAiU3VtbWFyeSBvZiBWb3Rpbmcgb24gRG9jdW1lbnQgNiBOIAAAAApKb29yYW4gTGVl Ckpvb3JhbiBMZWUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAAP7////9////FQAA AP7///8dAAAA/v/////////////////////////////////////////+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACA/RP5AZjAARQAAACAAwAAAAAAAFcAbwBy AGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF8gAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAagAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8EAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADcAQAAAAAAAAEAAAD+////AwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAP7///8LAAAADAAAAA0AAAD+//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////AQD+/wMKAAD/////AAkCAAAAAADA AAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3Jk LkRvY3VtZW50LjYA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoC AAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEgAAAAEAAACYAAAA AgAAAKAAAAADAAAAzAAAAAQAAADYAAAABQAAAOwAAAAGAAAA+AAAAAcAAAAEAQAACAAAABQBAAAJ AAAAKAEAABIAAAA0AQAACgAAAFwBAAALAAAAaAEAAAwAAAB0AQAADQAAAIABAAAOAAAAjAEAAA8A AACUAQAAEAAAAJwBAAATAAAApAEAAAIAAAC1AwAAHgAAACMAAABTdW1tYXJ5IG9mIFZvdGluZyBv biBEb2N1bWVudCA2IE4gAAAeAAAAAQAAAADaQgAeAAAACwAAAEpvb3JhbiBMZWUAAB4AAAABAAAA AABkAB4AAAABAAAAAP7/AB4AAAAHAAAATm9ybWFsAAAeAAAACwAAAEpvb3JhbiBMZWUAAB4AAAAD AAAAMTEAAB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFcFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAA AAAAAEYUAAAATWljcm9zb2Z0IFdvcmQgua68rQAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAAAAADAAAAHQAAAACAAAAtQMAAB4AAAAEAAAAS1NBAAMAAAAS AAAAAwAAAAQAAAALAAAAAAAAAAsAAAAAAAAADBAAAAIAAAAeAAAAIwAAAFN1bW1hcnkgb2YgVm90 aW5nIG9uIERvY3VtZW50IDYgTiAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaW5kb3dzIDk1AAAAQAAAAAAGLJwEAAAAQAAAAADO G/ddPb4BQAAAAAC+l1X6l8ABQAAAAACCyOABmMABAwAAAAEAAAADAAAAiwEAAAMAAADMCAAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAA AAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACwAAAABwAAAAEAAABAAAAADwAAAEgAAAAF AAAAVAAAAAYAAABcAAAACwAAAGQAAAAQAAAAbAAAAAwAAAB0AAAAAgAAALUDAAAeAAAABAAAAEtT QQADAAAAEgAAAAMAAAAEAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAACMAAABTdW1tYXJ5 IG9mIFZvdGluZyBvbiBEb2N1bWVudCA2IE4gAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: text/plain; name="ATT01250.txt" Content-Disposition: attachment; filename="ATT01250.txt" Content-Transfer-Encoding: 7bit -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer Phone: 469.255.1806 SP-Advanced Network Services Cisco Systems, Inc -- The Network Works, No Excuses ------=_NextPart_000_0012_01C0A0EC.CA6EF810-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 20:50:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09025 for ; Tue, 27 Feb 2001 20:50:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA36719; Tue, 27 Feb 2001 18:22:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA36707 for ; Tue, 27 Feb 2001 18:21:46 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1S1k8a45641 for ; Tue, 27 Feb 2001 17:46:08 -0800 (PST) X-JNPR-Received-From: outside 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 RAA20238; Tue, 27 Feb 2001 17:47:20 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 17:47:20 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DCA@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Learman'" , Radia Perlman - Boston Center for Networking Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.tx t 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 17:47:19 -0800 The requirements seem to me to actually be more complex than that. Not only do you have to track when you sent/received data, but also presumably the protocol i.e. it has to be the protocol(s) IS-IS is supporting - assuming you still care about CLNP at all. Further, if the IS-IS engine crashes on one end but the forwarding plane keeps working, then the adjacency is maintained until the much slower hello timer expires - which means you don't have fast detection any more. This linkage of control and data plane seems conceptually flawed. It is certainly ugly to implement in a distributed architecture - and not all that wonderful in a non-distributed architecture. There must be better ways to solve this problem than adding this baggage to the forwarding plane. Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Tuesday, February 27, 2001 3:08 PM > To: Radia Perlman - Boston Center for Networking > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.txt > > > > Perhaps I'm missing something, but ... > > >So to implement this: need an option in the Hello to say "I'm cool > >with receipt of data messages instead of Hellos". If your neighbor > >says that, then you don't have to send hellos in a timely way if > >you're sending traffic. > > ... you don't have to send hellos in a timely way if you're sending > traffic *via that adjacency*. So you'd need to > keep a new timer per adjacency of when you last sent data, and send > a Hello (either to that adjacency, or a broadcast) on timeout. > [Sorry, I don't remember whether the original proposal indicated > whether the hellos were direct or broadcast.] > > Is that what you mean? > > Thanks, > Jeff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 20:59:15 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09213 for ; Tue, 27 Feb 2001 20:59:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA36785; Tue, 27 Feb 2001 18:30:03 -0800 (PST) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA36770 for ; Tue, 27 Feb 2001 18:29:33 -0800 (PST) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA23858; Tue, 27 Feb 2001 17:55:04 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id RAA16380; Tue, 27 Feb 2001 17:55:04 -0800 (PST) Message-Id: <200102280155.RAA16380@cirrus.juniper.net> From: Dave Katz To: Radia.Perlman@east.sun.com CC: Radia.Perlman@east.sun.com, jlearman@cisco.com, isis-wg@juniper.net In-reply-to: <200102272326.SAA20260@bcn.East.Sun.COM> (message from Radia Perlman - Boston Center for Networking on Tue, 27 Feb 2001 18:26:01 -0500 (EST)) Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 17:55:04 -0800 (PST) All of this is a tad trickier in routers with silicon-based forwarding. Note that this still requires a sufficiently lively scheduler to make sure things happen within tight timeframes, which is the biggest impediment to this subsecond stuff. X-JNPR-Received-From: outside From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Cc: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Es5/WdGPyzDkEWfIBuXoJA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) I think what you said is what I mean. You would have to be aware of when you last sent something on each such adjacency to know whether you can postpone a hello on that adjacency. If you don't like that, would this be easier on the implementation? Having a nonzero queue of stuff to that adjacency would be sufficient information that you don't need to send a Hello on that adjacency. So, for instance, if the queue is empty, send a Hello...what harm is there since you're not doing anything anyway. But if the queue is nonempty, then you can skip actually transmitting that Hello. Radia X-Sender: jlearman@dingdong.cisco.com To: Radia Perlman - Boston Center for Networking From: Jeff Learman Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Cc: isis-wg@juniper.net Mime-Version: 1.0 Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 27 23:12:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12706 for ; Tue, 27 Feb 2001 23:12:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA37369; Tue, 27 Feb 2001 20:44:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA37357 for ; Tue, 27 Feb 2001 20:43:33 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1S47ra49104; Tue, 27 Feb 2001 20:07:53 -0800 (PST) X-JNPR-Received-From: outside Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA02905; Tue, 27 Feb 2001 20:09:08 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id UAA19749; Tue, 27 Feb 2001 20:09:08 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs From: Bora Akyol To: Dave Katz cc: Radia.Perlman@east.sun.com, jlearman@cisco.com, isis-wg@juniper.net Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt In-Reply-To: <200102280155.RAA16380@cirrus.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 20:09:08 -0800 (PST) I would second Dave here, keeping these timers on a per next hop basis and then generating these interrupts when these timers expire while doing line rate forwarding is a tad tricky. On a SONET link, it is fairly easy to detect that your neighbor has gone down and notify your peers. On an ethernet I do recognize this gets harder, but can we make do with a software based keep-alive mechanism that doesn't involve the forwarding plane? Regards Bora On Tue, 27 Feb 2001, Dave Katz wrote: > All of this is a tad trickier in routers with silicon-based forwarding. > > Note that this still requires a sufficiently lively scheduler to make > sure things happen within tight timeframes, which is the biggest impediment > to this subsecond stuff. > > > X-JNPR-Received-From: outside > From: Radia Perlman - Boston Center for Networking > Reply-To: Radia Perlman - Boston Center for Networking > Cc: isis-wg@juniper.net > MIME-Version: 1.0 > Content-Type: TEXT/plain; charset=us-ascii > Content-MD5: Es5/WdGPyzDkEWfIBuXoJA== > X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) > > I think what you said is what I mean. You would have to be > aware of when you last sent something on each such adjacency to know > whether you can postpone a hello on that adjacency. > > If you don't like that, would this be easier on the implementation? > Having a nonzero queue > of stuff to that adjacency would be sufficient information that > you don't need to send a Hello on that adjacency. So, for instance, > if the queue is empty, send a Hello...what harm is there since you're > not doing anything anyway. But if the queue is nonempty, then you > can skip actually transmitting that Hello. > > Radia > > X-Sender: jlearman@dingdong.cisco.com > To: Radia Perlman - Boston Center for Networking > From: Jeff Learman > Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt > Cc: isis-wg@juniper.net > Mime-Version: 1.0 > > > Perhaps I'm missing something, but ... > > >So to implement this: need an option in the Hello to say "I'm cool > >with receipt of data messages instead of Hellos". If your neighbor > >says that, then you don't have to send hellos in a timely way if > >you're sending traffic. > > ... you don't have to send hellos in a timely way if you're sending > traffic *via that adjacency*. So you'd need to > keep a new timer per adjacency of when you last sent data, and send > a Hello (either to that adjacency, or a broadcast) on timeout. > [Sorry, I don't remember whether the original proposal indicated > whether the hellos were direct or broadcast.] > > Is that what you mean? > > Thanks, > Jeff > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 06:10:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01726 for ; Wed, 28 Feb 2001 06:10:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA39216; Wed, 28 Feb 2001 03:41:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA39204 for ; Wed, 28 Feb 2001 03:40:55 -0800 (PST) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SB5Da55670 for ; Wed, 28 Feb 2001 03:05:13 -0800 (PST) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (uxb-dhcp-198-135-1-182.cisco.com [198.135.1.182]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06266; Wed, 28 Feb 2001 11:05:41 GMT Message-Id: <4.3.2.7.2.20010228105857.03384e30@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.tx t Cc: "'Jeff Learman'" , Radia Perlman - Boston Center for Networking , isis-wg@juniper.net In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA055DCA@avalon.pluris.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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 11:05:48 +0000 I agree. This worked very well in DECnet PhaseIV, but it may be somewhat ugly in modern system architectures. However can it be done by accessing the counter which the forwarding plane presumably already keeps for "management" purposes? I guess that depends on whether the counter can be polled every few hundred milliseconds. Mike At 17:47 27/02/2001 -0800, Les Ginsberg wrote: >The requirements seem to me to actually be more complex than that. Not only >do you have to track when you sent/received data, but also presumably the >protocol i.e. it has to be the protocol(s) IS-IS is supporting - assuming >you still care about CLNP at all. Further, if the IS-IS engine crashes on >one end but the forwarding plane keeps working, then the adjacency is >maintained until the much slower hello timer expires - which means you don't >have fast detection any more. > >This linkage of control and data plane seems conceptually flawed. It is >certainly ugly to implement in a distributed architecture - and not all that >wonderful in a non-distributed architecture. > >There must be better ways to solve this problem than adding this baggage to >the forwarding plane. > > Les > > > > > -----Original Message----- > > From: Jeff Learman [mailto:jlearman@cisco.com] > > Sent: Tuesday, February 27, 2001 3:08 PM > > To: Radia Perlman - Boston Center for Networking > > Cc: isis-wg@juniper.net > > Subject: Re: [Isis-wg] comment on > > draft-parker-short-isis-hold-times-00.txt > > > > > > > > Perhaps I'm missing something, but ... > > > > >So to implement this: need an option in the Hello to say "I'm cool > > >with receipt of data messages instead of Hellos". If your neighbor > > >says that, then you don't have to send hellos in a timely way if > > >you're sending traffic. > > > > ... you don't have to send hellos in a timely way if you're sending > > traffic *via that adjacency*. So you'd need to > > keep a new timer per adjacency of when you last sent data, and send > > a Hello (either to that adjacency, or a broadcast) on timeout. > > [Sorry, I don't remember whether the original proposal indicated > > whether the hellos were direct or broadcast.] > > > > Is that what you mean? > > > > Thanks, > > Jeff > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 06:58:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02914 for ; Wed, 28 Feb 2001 06:58:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA39480; Wed, 28 Feb 2001 04:30:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA39465 for ; Wed, 28 Feb 2001 04:29:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SBsEa56245 for ; Wed, 28 Feb 2001 03:54:14 -0800 (PST) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02125; Wed, 28 Feb 2001 06:55:31 -0500 (EST) Message-Id: <200102281155.GAA02125@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 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 06:55:30 -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 : M-ISIS: Multi Topology Routing in IS-IS Author(s) : T. Przygienda et al. Filename : draft-ietf-isis-wg-multi-topology-00.txt Pages : 7 Date : 27-Feb-01 This draft describes an optional implementation technique within IS-IS [ISO90 , Cal90a , Cal90b] 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, transport multiple overlapping IP address spaces in the same protocol, force a subset of an address space to follow a different topology, or finally, 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-00.txt 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-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-wg-multi-topology-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: <20010227123334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123334.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 08:48:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05825 for ; Wed, 28 Feb 2001 08:48:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA39978; Wed, 28 Feb 2001 06:19:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA39966 for ; Wed, 28 Feb 2001 06:18:01 -0800 (PST) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SDgIa58342 for ; Wed, 28 Feb 2001 05:42:18 -0800 (PST) X-JNPR-Received-From: outside Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id FAA16626 for ; Wed, 28 Feb 2001 05:43:19 -0800 (PST) Received: by src-news.pa.dec.com; id FAA17867; Wed, 28 Feb 2001 05:42:04 -0800 (PST) To: dec-mail-lists-ietf@usenet.pa.dec.com Path: pa.dec.com!owner-ietf-redist From: Internet-Drafts@ietf.org Newsgroups: dec.mail.lists.ietf Organization: Systems Research Center, Compaq Computer Corporation Lines: 88 Distribution: dec Message-ID: <200102281155.GAA02125@ietf.org> To: IETF-Announce:;;;;;;@pa.dec.com;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;@external.juniper.net;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;, ;;;;;;;;;;; Cc: isis-wg@juniper.net In-Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA00485 for ietf-123-outbound.02@ietf.org; Wed, 28 Feb 2001 08:05:01 -0500 (EST) X-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 GAA29702 for ; Wed, 28 Feb 2001 06:55:29 -0500 (EST) X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02125; Wed, 28 Feb 2001 06:55:31 -0500 (EST) X-Received: by src-news.pa.dec.com; id FAA25703; Wed, 28 Feb 2001 05:41:59 -0800 (PST) X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA19389; Wed, 28 Feb 2001 05:41:59 -0800 X-Received: from nsl-too.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA11866; Wed, 28 Feb 2001 05:41:58 -0800 X-Received: by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA13462; Wed, 28 Feb 2001 05:41:58 -0800 X-Received: from pobox1.pa.dec.com by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA14128; Wed, 28 Feb 2001 05:41:58 -0800 X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA19362; Wed, 28 Feb 2001 05:41:58 -0800 X-Received: from zmamail02.nz-tay.cpqcorp.net by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA06528; Wed, 28 Feb 2001 05:41:57 -0800 X-Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id A2D455619; Wed, 28 Feb 2001 08:41:56 -0500 (EST) X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 3F82C5E6D for ; Wed, 28 Feb 2001 08:41:56 -0500 (EST) Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 28 Feb 2001 05:42:02 -0800 --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 et al. Filename : draft-ietf-isis-wg-multi-topology-00.txt Pages : 7 Date : 27-Feb-01 This draft describes an optional implementation technique within IS-IS [ISO90 , Cal90a , Cal90b] 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, transport multiple overlapping IP address spaces in the same protocol, force a subset of an address space to follow a different topology, or finally, 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-00.txt 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-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-wg-multi-topology-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: <20010227123334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123334.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 10:11:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08723 for ; Wed, 28 Feb 2001 10:11:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA40492; Wed, 28 Feb 2001 07:42:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA40480 for ; Wed, 28 Feb 2001 07:41:53 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SF69a61040 for ; Wed, 28 Feb 2001 07:06:09 -0800 (PST) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Bora Akyol'" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 10:06:46 -0500 > I would second Dave here, keeping these timers on a per next > hop basis and then generating these interrupts when these > timers expire while doing line rate forwarding is a tad tricky. > > On a SONET link, it is fairly easy to detect that your > neighbor has gone down and notify your peers. On an ethernet > I do recognize this gets harder, but can we make do with a > software based keep-alive mechanism that doesn't involve the > forwarding plane? > > Regards > > Bora Bora - While I don't want to conflate Radia's proposal with the draft, the draft tries to be clear in section 8.1 that anytime Level 2 information tells us that a link is down, we should delete any adjacencies on that link. Reacting to Physical Link failures is one of those things that I think everyone agrees is a Good Thing. Van, Cengiz and company have just pointed out that sometimes we forget to implement things that we all know are good. The Hello PDUs act as the software based keep-alive mechanism that you mention. There has been some interest expressed in playing with lower TTLs in this mechanism: this draft is trying to suggest a common format for such experiments. We return now to our regular bashing of the concept that we can meet any schedules with deadlines under 30 seconds. - jeff parker - Entropy ain't what it used to be _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 12:31:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15205 for ; Wed, 28 Feb 2001 12:31:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41121; Wed, 28 Feb 2001 10:02:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41109 for ; Wed, 28 Feb 2001 10:01:38 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SHPsa66655 for ; Wed, 28 Feb 2001 09:25:54 -0800 (PST) X-JNPR-Received-From: outside Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA10262; Wed, 28 Feb 2001 09:27:04 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: To: Jeff Parker From: Bora Akyol Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Cc: "'Bora Akyol'" , isis-wg@juniper.net 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 09:25:11 -0800 Following up on this thread, on BGP the recommended behavior is to not use a timer for withdrawals when adjacencies fail, can one utilize a similar behavior and immediately generate and distribute updated LSPs when L2 link is lost? Bora At 10:06 AM -0500 2/28/01, Jeff Parker wrote: > > I would second Dave here, keeping these timers on a per next >> hop basis and then generating these interrupts when these >> timers expire while doing line rate forwarding is a tad tricky. >> >> On a SONET link, it is fairly easy to detect that your >> neighbor has gone down and notify your peers. On an ethernet >> I do recognize this gets harder, but can we make do with a >> software based keep-alive mechanism that doesn't involve the >> forwarding plane? >> >> Regards >> >> Bora > > >Bora - > >While I don't want to conflate Radia's proposal with the draft, >the draft tries to be clear in section 8.1 that anytime Level 2 >information tells us that a link is down, we should delete any >adjacencies on that link. > >Reacting to Physical Link failures is one of those things that >I think everyone agrees is a Good Thing. Van, Cengiz and >company have just pointed out that sometimes we forget to >implement things that we all know are good. > >The Hello PDUs act as the software based keep-alive mechanism >that you mention. There has been some interest expressed >in playing with lower TTLs in this mechanism: this draft is >trying to suggest a common format for such experiments. > >We return now to our regular bashing of the concept that >we can meet any schedules with deadlines under 30 seconds. > >- jeff parker >- Entropy ain't what it used to be _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 13:33:34 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18111 for ; Wed, 28 Feb 2001 13:33:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA41418; Wed, 28 Feb 2001 11:04:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA41406 for ; Wed, 28 Feb 2001 11:03:54 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SIS8a69858 for ; Wed, 28 Feb 2001 10:28:08 -0800 (PST) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Bora Akyol'" , "Danny McPherson (E-mail)" , "Cengiz Alaettinoglu (E-mail)" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 13:28:35 -0500 > Following up on this thread, on BGP the recommended behavior is to > not use a timer for withdrawals when adjacencies fail, can one > utilize a similar behavior and immediately generate and distribute > updated LSPs when L2 link is lost? > > Bora Bora - Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a hold-down timer on the regeneration of an particular LSP with a default value of 30 seconds. I assume this means that we could generate the first LSP after an Adjacency change at once, though regeneration due to later events would be damped by this value. That is, I read this to say that regeneration could happen right after the first adjacency was lost, recording the time until the next regeneration would be valid. It may be more common to see implementations simply start a timer to schedule regeneration in the future, which may be a bit simpler, and has the nice tendency to group more events into one generation, suffering the problem of increasing the convergence time. Is there any reason why we should not encourage Bora's interpretation for Adjacency Loss? I could defend a distinction between adjacency loss and things like metric change or a change in the DIS, as those do not prevent a packet from reaching its destination. - jparker - axiowave networks - If you want truly to understand something, try to change it. - Kurt Lewin _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 14:32:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20254 for ; Wed, 28 Feb 2001 14:32:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41717; Wed, 28 Feb 2001 12:04:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41705 for ; Wed, 28 Feb 2001 12:03:28 -0800 (PST) Received: from pefw00.ivmg.net ([64.209.84.66]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SJRga72556 for ; Wed, 28 Feb 2001 11:27:42 -0800 (PST) X-JNPR-Received-From: outside Received: from pimx00.ivmg.net (pimx00.ivmg.net [192.168.0.10]) by pefw00.ivmg.net (iVMG) with ESMTP id f1SJSxh59303 for ; Wed, 28 Feb 2001 19:28:59 GMT Received: (from serge@localhost) by pimx00.ivmg.net (iVMG) id f1SJSxm06292 for isis-wg@juniper.net; Wed, 28 Feb 2001 11:28:59 -0800 From: Serge Maskalik To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt Message-ID: <20010228112859.C27593@ivmg.net> References: <200102281155.GAA02125@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200102281155.GAA02125@ietf.org>; from Internet-Drafts@ietf.org on Wed, Feb 28, 2001 at 06:55:30AM -0500 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 11:28:59 -0800 Tony et al., Outside of the protocol-based VPN (limited amount), the benefits of having multiple parallel IGP topologies is not obvious to me. Even the VPNs are questionable. Can you explain why someone would want a different topology for and in-band management network? Are there NSPs asking for this functionality? - Serge Thus spake Internet-Drafts@ietf.org (Internet-Drafts@ietf.org): > 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 et al. > Filename : draft-ietf-isis-wg-multi-topology-00.txt > Pages : 7 > Date : 27-Feb-01 > > This draft describes an optional implementation technique within > IS-IS [ISO90 , Cal90a , Cal90b] 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, transport multiple > overlapping IP address spaces in the same protocol, force a subset > of an address space to follow a different topology, or finally, > 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-00.txt > > 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-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-wg-multi-topology-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. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 14:56:11 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21244 for ; Wed, 28 Feb 2001 14:56:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41838; Wed, 28 Feb 2001 12:27:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41826 for ; Wed, 28 Feb 2001 12:26:41 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SJota73668 for ; Wed, 28 Feb 2001 11:50:55 -0800 (PST) X-JNPR-Received-From: outside 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 LAA25422; Wed, 28 Feb 2001 11:52:07 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 11:52:06 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Parker'" , Bora Akyol , "Danny McPherson (E-mail)" , "Cengiz Alaettinoglu (E-mail)" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 11:51:59 -0800 If faster convergence is to be achieved and be useful, then clearly all aspects must be addressed - adjacency state change detection, propagation, SPF performance, and forwarding database update. It does no good to detect an adjacency failure in milliseconds if you can't tell anyone about it until 30 seconds later. So clearly minimumLSPGenerationInterval needs to be adjusted as well as the hold down timer on the SPF. All of these issues are mentioned in Cengiz et al draft. I also think that treating adjacency state change as a "special" kind of update is unnecessary. So long as we are not talking about leaking BGP routes into IS-IS, adjacency flapping has to be the primary cause of LSP updates in a network. Les > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Wednesday, February 28, 2001 10:29 AM > To: 'Bora Akyol'; Danny McPherson (E-mail); Cengiz > Alaettinoglu (E-mail) > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.t xt > > > > Following up on this thread, on BGP the recommended behavior is to > > not use a timer for withdrawals when adjacencies fail, can one > > utilize a similar behavior and immediately generate and distribute > > updated LSPs when L2 link is lost? > > > > Bora > > Bora - > > Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a > hold-down > timer on the regeneration of an particular LSP with a default > value of 30 > seconds. > I assume this means that we could generate the first LSP > after an Adjacency > change > at once, though regeneration due to later events would be > damped by this > value. > > That is, I read this to say that regeneration could happen right > after the first adjacency was lost, recording the time until the > next regeneration would be valid. > It may be more common to see implementations simply start a timer > to schedule regeneration in the future, which may be a bit simpler, > and has the nice tendency to group more events into one generation, > suffering the problem of increasing the convergence time. > > Is there any reason why we should not encourage Bora's interpretation > for Adjacency Loss? I could defend a distinction between adjacency > loss and things like metric change or a change in the DIS, as those > do not prevent a packet from reaching its destination. > > - jparker > - axiowave networks > - If you want truly to understand something, try to change > it. - Kurt Lewin > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 15:01:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21675 for ; Wed, 28 Feb 2001 15:01:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41892; Wed, 28 Feb 2001 12:32:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41875 for ; Wed, 28 Feb 2001 12:31:25 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SJtca73869 for ; Wed, 28 Feb 2001 11:55:39 -0800 (PST) X-JNPR-Received-From: outside Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA26102; Wed, 28 Feb 2001 11:56:55 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> References: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> To: Les Ginsberg From: Bora Akyol Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Cc: isis-wg@juniper.net 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 11:55:06 -0800 As long as you generate LSP updates when the adjacency is dropped quickly and you apply some sort of backoff interval when the adjacency comes back, is there any reason that you can not generate an LSP update immediately when adjacencies are lost (via L2 notification)? Bora At 11:51 AM -0800 2/28/01, Les Ginsberg wrote: >If faster convergence is to be achieved and be useful, then clearly all >aspects must be addressed - adjacency state change detection, >propagation, SPF performance, and forwarding database update. It does no >good to detect an adjacency failure in milliseconds if you can't tell >anyone about it until 30 seconds later. So clearly >minimumLSPGenerationInterval needs to be adjusted as well as the hold >down timer on the SPF. All of these issues are mentioned in Cengiz et al >draft. > >I also think that treating adjacency state change as a "special" kind of >update is unnecessary. So long as we are not talking about leaking BGP >routes into IS-IS, adjacency flapping has to be the primary cause of LSP >updates in a network. > > Les > > >> -----Original Message----- >> From: Jeff Parker [mailto:jparker@axiowave.com] >> Sent: Wednesday, February 28, 2001 10:29 AM >> To: 'Bora Akyol'; Danny McPherson (E-mail); Cengiz >> Alaettinoglu (E-mail) >> Cc: isis-wg@juniper.net >> Subject: RE: [Isis-wg] comment on >> draft-parker-short-isis-hold-times-00.t xt >> >> >> > Following up on this thread, on BGP the recommended behavior is to >> > not use a timer for withdrawals when adjacencies fail, can one >> > utilize a similar behavior and immediately generate and distribute >> > updated LSPs when L2 link is lost? >> > >> > Bora >> >> Bora - >> >> Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a >> hold-down >> timer on the regeneration of an particular LSP with a default >> value of 30 >> seconds. >> I assume this means that we could generate the first LSP >> after an Adjacency >> change >> at once, though regeneration due to later events would be >> damped by this >> value. >> >> That is, I read this to say that regeneration could happen right >> after the first adjacency was lost, recording the time until the >> next regeneration would be valid. >> It may be more common to see implementations simply start a timer >> to schedule regeneration in the future, which may be a bit simpler, >> and has the nice tendency to group more events into one generation, >> suffering the problem of increasing the convergence time. >> >> Is there any reason why we should not encourage Bora's interpretation >> for Adjacency Loss? I could defend a distinction between adjacency >> loss and things like metric change or a change in the DIS, as those >> do not prevent a packet from reaching its destination. >> >> - jparker >> - axiowave networks >> - If you want truly to understand something, try to change >> it. - Kurt Lewin >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 15:04:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21855 for ; Wed, 28 Feb 2001 15:04:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41965; Wed, 28 Feb 2001 12:36:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA41949 for ; Wed, 28 Feb 2001 12:35:58 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SK0Ba74085 for ; Wed, 28 Feb 2001 12:00:12 -0800 (PST) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Jeff Parker , Bora Akyol , "Danny McPherson (E-mail)" , "Cengiz Alaettinoglu (E-mail)" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 15:00:40 -0500 Les - I agree that getting the LSP out quickly is important. I guess I haven't seen where it is written in stone that "hold-down timer" means "don't do something until X seconds elapse" rather than "don't do this more often than once every X seconds." The first is an easy way to implement the second, but not the only way. Given the second interpretation, we could still get rapid convergence while keeping a large minLSPGen time, which is desirable. - jdp > If faster convergence is to be achieved and be useful, then > clearly all > aspects must be addressed - adjacency state change detection, > propagation, > SPF performance, and forwarding database update. It does no > good to detect > an adjacency failure in milliseconds if you can't tell anyone > about it until > 30 seconds later. So clearly minimumLSPGenerationInterval needs to be > adjusted as well as the hold down timer on the SPF. All of > these issues are > mentioned in Cengiz et al draft. > > I also think that treating adjacency state change as a > "special" kind of > update is unnecessary. So long as we are not talking about leaking BGP > routes into IS-IS, adjacency flapping has to be the primary > cause of LSP > updates in a network. > > Les > > > That is, I read this to say that regeneration could happen right > > after the first adjacency was lost, recording the time until the > > next regeneration would be valid. > > It may be more common to see implementations simply start a timer > > to schedule regeneration in the future, which may be a bit simpler, > > and has the nice tendency to group more events into one generation, > > suffering the problem of increasing the convergence time. > > > > - jparker > > - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 15:18:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22419 for ; Wed, 28 Feb 2001 15:18:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA42141; Wed, 28 Feb 2001 12:50:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA42125 for ; Wed, 28 Feb 2001 12:49:55 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SKE9a74740 for ; Wed, 28 Feb 2001 12:14:09 -0800 (PST) X-JNPR-Received-From: outside 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 MAA28052; Wed, 28 Feb 2001 12:15:17 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 12:15:16 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DD0@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Parker'" , Les Ginsberg , Bora Akyol , "Danny McPherson (E-mail)" , "Cengiz Alaettinoglu (E-mail)" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 12:15:13 -0800 So long as you have a large minLSPgen timer, no matter which implementation method you use, the best you can do is get fast convergence on one adjacency change. If two events occur over a short time span then even the second interpretation would have to wait 30 seconds to propagate the second change. So if you think that minLSPgen needs to be large, then its pretty much a waste of time to do sub-second adjacency timeout. Note that I am not in opposition to the faster convergence concept - just want to be sure all aspects are addressed. Les > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Wednesday, February 28, 2001 12:01 PM > To: 'Les Ginsberg'; Jeff Parker; Bora Akyol; Danny McPherson (E-mail); > Cengiz Alaettinoglu (E-mail) > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.t xt > > > Les - > I agree that getting the LSP out quickly is important. > I guess I haven't seen where it is written in stone that > "hold-down timer" means "don't do something until X seconds elapse" > rather than "don't do this more often than once every X seconds." > The first is an easy way to implement the second, but not the > only way. > Given the second interpretation, we could still get rapid > convergence while keeping a large minLSPGen time, which is > desirable. > > - jdp > > > If faster convergence is to be achieved and be useful, then > > clearly all > > aspects must be addressed - adjacency state change detection, > > propagation, > > SPF performance, and forwarding database update. It does no > > good to detect > > an adjacency failure in milliseconds if you can't tell anyone > > about it until > > 30 seconds later. So clearly minimumLSPGenerationInterval > needs to be > > adjusted as well as the hold down timer on the SPF. All of > > these issues are > > mentioned in Cengiz et al draft. > > > > I also think that treating adjacency state change as a > > "special" kind of > > update is unnecessary. So long as we are not talking about > leaking BGP > > routes into IS-IS, adjacency flapping has to be the primary > > cause of LSP > > updates in a network. > > > > Les > > > > > That is, I read this to say that regeneration could happen right > > > after the first adjacency was lost, recording the time until the > > > next regeneration would be valid. > > > It may be more common to see implementations simply start a timer > > > to schedule regeneration in the future, which may be a > bit simpler, > > > and has the nice tendency to group more events into one > generation, > > > suffering the problem of increasing the convergence time. > > > > > > - jparker > > > - axiowave networks > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 15:44:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23782 for ; Wed, 28 Feb 2001 15:44:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA42339; Wed, 28 Feb 2001 13:16:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA42327 for ; Wed, 28 Feb 2001 13:15:12 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f1SKdQa80384 for ; Wed, 28 Feb 2001 12:39:26 -0800 (PST) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Bora Akyol'" , Les Ginsberg Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 15:40:07 -0500 > As long as you generate LSP updates when the adjacency is dropped > quickly and you apply some sort of backoff interval when the > adjacency comes back, is there any reason that you can not generate > an LSP update immediately when adjacencies are lost (via L2 > notification)? > > Bora and > So long as you have a large minLSPgen timer, [when] .. > two events occur over a short time span [you]... > would have to wait 30 seconds to propagate the > second change.... > > Note that I am not in opposition to the faster convergence > concept - just want to be sure all aspects are addressed. > > Les Good points both. I see the goals as o Fast Response to change o Stable Networks which starts with a basic tension. The adjacency damping is really there to reduce the number of LSP re-generations. Perhaps it would be better to focus on controling that directly. I think we still want to preserve the notion of "quick loss, slow win", so that losing an adjacency would result in a quick LSP regen, while addition of an adjacency could wait. We also want to preserve some overall rate limiting mechanism on the frequence of LSP regeneration: perhaps an exponential backoff that affects even the fast-twitch Adjacency-loss regen. Perhaps we could take this off-list and come up with a proposal? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 28 20:09:20 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04287 for ; Wed, 28 Feb 2001 20:09:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA43512; Wed, 28 Feb 2001 17:39:03 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA43500 for ; Wed, 28 Feb 2001 17:38:43 -0800 (PST) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f2112ta91687 for ; Wed, 28 Feb 2001 17:02:55 -0800 (PST) X-JNPR-Received-From: outside Received: from AZININ-W2K.cisco.com (dhcp-171-69-103-174.cisco.com [171.69.103.174]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA24333; Wed, 28 Feb 2001 17:03:05 -0800 (PST) From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <2707.010228@cisco.com> To: Jeff Parker CC: "'Bora Akyol'" , Les Ginsberg , isis-wg@juniper.net Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt In-reply-To: References: 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Feb 2001 16:58:57 -0800 Content-Transfer-Encoding: 7bit A small comment here. While we do want to exponentially (with a considerably wide range of delay values) dampen interfaces and adjacencies, LSP origination should still be paced with a constant max rate even if the starting part of the delay curve goes exponentially. Alex. > Good points both. I see the goals as > o Fast Response to change > o Stable Networks > which starts with a basic tension. > The adjacency damping is really there to reduce the > number of LSP re-generations. Perhaps it would be > better to focus on controling that directly. > I think we still want to preserve the notion of "quick loss, > slow win", so that losing an adjacency would result in a quick > LSP regen, while addition of an adjacency could wait. > We also want to preserve some overall rate limiting mechanism > on the frequence of LSP regeneration: perhaps an exponential > backoff that affects even the fast-twitch Adjacency-loss regen. > Perhaps we could take this off-list and come up with a proposal? > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg