From isis-wg-admin@spider.juniper.net Mon Jun 3 15:32:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28517 for ; Mon, 3 Jun 2002 15:32:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g53J91t07799; Mon, 3 Jun 2002 12:09:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g53J2st07763 for ; Mon, 3 Jun 2002 12:02:54 -0700 (PDT) (envelope-from zinin@psg.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g53JKUX05970 for ; Mon, 3 Jun 2002 12:20:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from psg.com ([147.28.0.62]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 3 Jun 2002 12:18:12 -0700 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17ExLd-000OQI-00; Mon, 03 Jun 2002 12:18:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1359636974.20020603121812@psg.com> To: "Amir Hermelin" CC: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2002 19:18:12.0789 (UTC) FILETIME=[67865650:01C20B33] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 3 Jun 2002 12:18:12 -0700 Content-Transfer-Encoding: 7bit Amir, > Alex, > comments inline. Thanks very much for the helpful comments and suggestions. > As always, other suggetions, especially for terminology, are more than welcomed. ... >> > Extended system-id >> >> Sounds like we're stretching out the normal system-id. >> Maybe "Virtual system-id" would be a better choice? >> > again, could be bad naming. However, I originally thought "Virtual" to be a little confusing, > as a "virtual link" term is already used in the IS-IS spec, for a completely different purpose. The > draft uses "extended" for LSPs, since they really extend the original LS information an IS could advertise, > as opposed to "Virtual System", which doesn't really add any additional info. Does that > make sense? "extended" LSPs, though not perfect, make more sense--I couldn't come up with a better name, maybe native English speakers can :) >> > These modes may be configured per level. There is no restriction >> > that an L1/L2 IS operates in the same mode, for both L1 and L2. >> >> Shouldn't the modes be on a per-level & area basis. This >> text also sounds like all routers within a level (or an area >> if corrected) need to work in the same mode, which is not true, >> since modified SPF is a requirement regardless of the LSP >> origination mode. > agreed, that's the original intent. I'll add "per area". The actual requirement > is "per spf", but I think it will confuse more than it will clarify. Agreed. >> >> > 2.0 IS Alias ID TLV (IS-A) >> > >> > The proposed IS-A TLV allows extension-capable ISs to >> recognize all >> > LSPs of an Originating System, and combine the original >> and extended >> > LSPs for the purpose of SPF computation. >> > >> > The IS Alias ID TLV is type 24, and contains a new data >> structure, >> > consisting of: >> > 7 octets of system Id and pseudonode number >> > 1 octet of length of sub-TLVs >> > 0-247 octets of sub-TLVs, >> > where each sub-TLV consists of a sequence of >> > 1 octet of sub-type >> > 1 octet of length >> > 0-245 octets of value >> > >> > Without sub-TLVs, this structure consumes 8 octets per >> LSP set. This >> > TLV MUST be included in fragment 0 of every LSP set >> belonging to an >> > Originating System. >> >> Couldn't find any info on how to put S' and S'' in the TLV. >> > Actually, what you need to put here is S (or the is-alias-id, which > could be different). The S' and S'' (and also S) appear in the LSP header. I think I was confused by the illustration. Could you please specify more explicitly which ID is put in the TLV. >> Couldn't find description of any sub-TLVs that would be >> used to do the above. > It's just put there for future or proprietary use - doesn't take up > any space, I think we should keep it. No objection to this, but you need to describe sub-TLV handling properly. >> >> Couldn't find any rules about sub-TLV handling, i.e., padding >> and length calculation with it. >> >> The format description above should use the illustration >> style from 1195. > I don't fully understand what's missing, but I will add an example. > I've used the format from the TE-extensions draft, which I think to be > clear and well-discussed. Please clarify what you'd like to see here. I'd like the TLV format illustration to be consistent with 1195, i.e., something like this: x CODE - 24 x LENGTH - total length of the value field. x VALUE - the following data: No. of Octets +--------------------------------+ | ALIAS SYSTEM ID | 7 +--------------------------------+ | SUB-TLV LENGTH | 1 +--------------------------------+ | | . SUB-TLVs . | | +--------------------------------+ >> What about the OL bit? > The 3.1.* sections are exceptions. The OL bit should be set/unset in original and extended LSPs the same as before. Don't we want to have consistent values in the "normal" and "extended" LSPs, at least for mode 2? >> > 3.2 Operation Mode 1 Additions >> ... >> > When an extended LSP belonging to extended system-id S' is first >> > created, the original LSP MUST specify S' as a neighbor, >> with metric >> > set to zero. This in order to satisfy the two-way >> connectivity check >> > on other routers, as well as to consider the cost of reaching the >> >> I thought that the S'->S link would be needed to satisfy >> the TWC check for the S->S' one, not the other way around... >> > Depends on which node (S or S') was first considered in SPF. In Mode 1, it's true > that always S will be reached first, but this isn't guaranteed in mode 2. Note the name of the section where this text belongs ;) >> > 4. Purging Extended LSP Fragments >> ... >> > However, an extended LSP fragment >> zero should not >> > be purged until all of the fragments in its set (i.e. >> belonging to a >> > particular extended system-id), are empty as well. This >> is to ensure >> > implementations consider the fragments in their SPF >> computations, as >> > specified in section 7.2.5. >> >> Given what section 5 says about ignoring non-0 fragments when >> fragment zero is missing, what does the above rule give us? >> > the above rule is specifically to ensure section 5 works well: if we have > info in other fragments, but the zero-fragment is empty (and we don't re-arrange > information, as we shouldn't), we still need to keep that fragment so other fragments > are considered. I guess this is true regardless of this draft or not - we just wanted > to clarify it. Makes sense. >> We don't have to go through mode-1 to get to mode-2. An upgrade of >> SW does not necessarily mean changing the LSP origination process. >> In fact, I would argue that the default setting MUST be the standard >> one, i.e., neither mode 1 nor mode 2, and it would be really great >> if this was spelled out. >> > Your upgrade option is identical to what the draft suggests - since "standard one" > is really Mode 1 (you can either have mode-1 or mode-2). The difference between mode-1 > and the "standard" way, is that the standard way asserts when the maximum fragments > are reached ;-) There's also the additional tlv, but there's no harm in advertising it. I don't agree here. I think the most common case will be where the network works and routers' SW gets upgraded. Once upgraded the LSP origination behavior should not change, i.e., neither mode-1 nor mode-2 should be activated until explicitly configured by the admin. This should save from problems with implementations that for some buggy reason react incorrectly to 0-cost links in non-pseudo LSPs, or with implementations that implement your spec incorrectly, as well as this is just a good general practice to not enable new behavior by default, especially in routing protocols. Thanks. Alex _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 3 16:54:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00638 for ; Mon, 3 Jun 2002 16:54:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g53KVBt08217; Mon, 3 Jun 2002 13:31:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TMJIt70497 for ; Wed, 29 May 2002 15:19:18 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" , joyal@lucent.com, Jeff Parker , satish@pluris.com Cc: isis-wg@spider.juniper.net, "Jim Halpin (E-mail)" , "Bert Wijnen (Bert) (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 29 May 2002 18:35:54 -0400 > Index by the level and the LSP ID. Have an attribute for each > of the fixed fields. Have an OCTET-STRING defined attribute > as the last entry in the table that contains either: > a. The hex dump of the entire LSP, or > b. The hex dump of just the variable length fields. > The upper bound on the size probably needs to be 65535. Don't > worry, SNMP can fragment SNMP replies for the large one. > Don Don - I was under the impression that SNMP couldn't deal with 1492 byte or larger objects. If it can, I would be happy to package up the whole LSP and ship it over so that the clients can do what they like. But Dan suggested last week that this is not possible. Is there a MIB Doctor in the house? Can we get a ruling on shiping 1492 to 4K to larger yet blobs as one object? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 3 19:28:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04086 for ; Mon, 3 Jun 2002 19:28:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g53N5Bt08988; Mon, 3 Jun 2002 16:05:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xmxpita.excite.com (nat1.excitenetwork.com [63.236.75.3]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TMght70624 for ; Wed, 29 May 2002 15:42:43 -0700 (PDT) (envelope-from dgoodspe@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id A75B0B703; Wed, 29 May 2002 18:59:43 -0400 (EDT) To: jparker@axiowave.com, dgoodspe@excite.com, joyal@lucent.com, jparker@axiowave.com, satish@pluris.com Subject: RE: [Isis-wg] IS-IS MIB Received: from [63.104.212.252] by xprdmailfe20.nwk.excite.com via HTTP; Wed, 29 May 2002 18:59:43 EST Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6"; Content-Transfer-Encoding: 7bit Cc: isis-wg@spider.juniper.net, jhalpin@charter.net, bwijnen@lucent.com Message-Id: <20020529225943.A75B0B703@xmxpita.excite.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 29 May 2002 18:59:43 -0400 (EDT) --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If supported, IP can fragment the SNMP Response PDU if it's larger than the MTU. I've tested this before with large OSPF router LSAs. (I test both IGP protocols and SNMP, btw). The only references to large PDUs in SMIv2 I can find are a warning on any octet string over 255 characters, and having the ability to give a "tooBig" error if a local constraint is exceeded on the agent. -don --- On Wed 05/29, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com,joyal@lucent.com,jparker@axiowave.com,satish@pluris.com Cc: isis-wg@spider.juniper.net,jhalpin@charter.net,bwijnen@lucent.com Date: Wed 05/29 Subject: RE: [Isis-wg] IS-IS MIB > > Index by the level and the LSP ID. Have an attribute for each > > of the fixed fields. Have an OCTET-STRING defined attribute > > as the last entry in the table that contains either: > > a. The hex dump of the entire LSP, or > > b. The hex dump of just the variable length fields. > > > The upper bound on the size probably needs to be 65535. Don't > > worry, SNMP can fragment SNMP replies for the large one. > > > Don > > Don - > I was under the impression that SNMP couldn't deal with > 1492 byte or larger objects. If it can, I would be happy to > package up the whole LSP and ship it over so that the clients > can do what they like. > But Dan suggested last week that this is not possible. > > Is there a MIB Doctor in the house? Can we get a ruling > on shiping 1492 to 4K to larger yet blobs as one object? > > - jeff parker > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit If supported, IP can fragment the SNMP Response PDU if it's
larger than the MTU. I've tested this before with large OSPF
router LSAs. (I test both IGP protocols and SNMP, btw).

The only references to large PDUs in SMIv2 I can find are a
warning on any octet string over 255 characters, and having the
ability to give a "tooBig" error if a local constraint is exceeded
on the agent.

-don

--- On Wed 05/29, Jeff Parker < jparker@axiowave.com > wrote:
From: Jeff Parker [mailto: jparker@axiowave.com]
To: dgoodspe@excite.com,joyal@lucent.com,jparker@axiowave.com,satish@pluris.com
Cc: isis-wg@spider.juniper.net,jhalpin@charter.net,bwijnen@lucent.com
Date: Wed 05/29
Subject: RE: [Isis-wg] IS-IS MIB
> > Index by the level and the LSP ID. Have an attribute for each
> > of the fixed fields. Have an OCTET-STRING defined attribute
> > as the last entry in the table that contains either:
> > a. The hex dump of the entire LSP, or
> > b. The hex dump of just the variable length fields.
>
> > The upper bound on the size probably needs to be 65535. Don't
> > worry, SNMP can fragment SNMP replies for the large one.
>
> > Don
>
> Don -
> I was under the impression that SNMP couldn't deal with
> 1492 byte or larger objects. If it can, I would be happy to
> package up the whole LSP and ship it over so that the clients
> can do what they like.
> But Dan suggested last week that this is not possible.
>
> Is there a MIB Doctor in the house? Can we get a ruling
> on shiping 1492 to 4K to larger yet blobs as one object?
>
> - jeff parker
>

Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 08:28:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25548 for ; Tue, 4 Jun 2002 08:28:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54C74t13364; Tue, 4 Jun 2002 05:07:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A5fit16467 for ; Tue, 9 Apr 2002 22:41:44 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B18F21DCC6C; Tue, 9 Apr 2002 22:53:35 -0700 (PDT) To: stefano previdi Cc: Naiming Shen , Hannes Gredler , "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from stefano previdi dated Wed, 10 Apr 2002 03:02:32 +0200 <200204100102.DAA12879@strange-brew.cisco.com> From: Naiming Shen Message-Id: <20020410055335.B18F21DCC6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 22:53:35 -0700 ] On Tuesday 09 April 2002 23:41, Naiming Shen wrote: ] > If one is going to make it a 64-bit tag, it maybe good to make it ] > a variable size(n x 32bits) to accommodate future "crazy" applications. ] ] after some thoughts and discussions it came out that the best ] way is probably to define one subTLV for 32bits tags and another ] subTLV for 64bits ones. ] that works for me too. if someone later on need a different one, they just need to have a third subTLV, say 256 bits wide... thanks. ] s. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 09:07:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26686 for ; Tue, 4 Jun 2002 09:07:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54CjXt13595; Tue, 4 Jun 2002 05:45:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A5fit16467 for ; Tue, 9 Apr 2002 22:41:44 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B18F21DCC6C; Tue, 9 Apr 2002 22:53:35 -0700 (PDT) To: stefano previdi Cc: Naiming Shen , Hannes Gredler , "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from stefano previdi dated Wed, 10 Apr 2002 03:02:32 +0200 <200204100102.DAA12879@strange-brew.cisco.com> From: Naiming Shen Message-Id: <20020410055335.B18F21DCC6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 22:53:35 -0700 ] On Tuesday 09 April 2002 23:41, Naiming Shen wrote: ] > If one is going to make it a 64-bit tag, it maybe good to make it ] > a variable size(n x 32bits) to accommodate future "crazy" applications. ] ] after some thoughts and discussions it came out that the best ] way is probably to define one subTLV for 32bits tags and another ] subTLV for 64bits ones. ] that works for me too. if someone later on need a different one, they just need to have a third subTLV, say 256 bits wide... thanks. ] s. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 09:25:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27750 for ; Tue, 4 Jun 2002 09:25:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54D3Xt13699; Tue, 4 Jun 2002 06:03:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A5fit16467 for ; Tue, 9 Apr 2002 22:41:44 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B18F21DCC6C; Tue, 9 Apr 2002 22:53:35 -0700 (PDT) To: stefano previdi Cc: Naiming Shen , Hannes Gredler , "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from stefano previdi dated Wed, 10 Apr 2002 03:02:32 +0200 <200204100102.DAA12879@strange-brew.cisco.com> From: Naiming Shen Message-Id: <20020410055335.B18F21DCC6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 22:53:35 -0700 ] On Tuesday 09 April 2002 23:41, Naiming Shen wrote: ] > If one is going to make it a 64-bit tag, it maybe good to make it ] > a variable size(n x 32bits) to accommodate future "crazy" applications. ] ] after some thoughts and discussions it came out that the best ] way is probably to define one subTLV for 32bits tags and another ] subTLV for 64bits ones. ] that works for me too. if someone later on need a different one, they just need to have a third subTLV, say 256 bits wide... thanks. ] s. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 09:42:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28370 for ; Tue, 4 Jun 2002 09:42:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54DKYt13804; Tue, 4 Jun 2002 06:20:34 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g3A5fit16467 for ; Tue, 9 Apr 2002 22:41:44 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B18F21DCC6C; Tue, 9 Apr 2002 22:53:35 -0700 (PDT) To: stefano previdi Cc: Naiming Shen , Hannes Gredler , "Martin, Christian" , bneal@broadwing.com, kireeti@juniper.net, nsheth@juniper.net, yakov@juniper.net, danny@tcb.net, prz@redback.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02 In-reply-to: Mail from stefano previdi dated Wed, 10 Apr 2002 03:02:32 +0200 <200204100102.DAA12879@strange-brew.cisco.com> From: Naiming Shen Message-Id: <20020410055335.B18F21DCC6C@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 22:53:35 -0700 ] On Tuesday 09 April 2002 23:41, Naiming Shen wrote: ] > If one is going to make it a 64-bit tag, it maybe good to make it ] > a variable size(n x 32bits) to accommodate future "crazy" applications. ] ] after some thoughts and discussions it came out that the best ] way is probably to define one subTLV for 32bits tags and another ] subTLV for 64bits ones. ] that works for me too. if someone later on need a different one, they just need to have a third subTLV, say 256 bits wide... thanks. ] s. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 09:49:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28573 for ; Tue, 4 Jun 2002 09:49:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54DRht13867; Tue, 4 Jun 2002 06:27:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54DEut13767 for ; Tue, 4 Jun 2002 06:14:56 -0700 (PDT) (envelope-from rameshrr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g54DWbX24493 for ; Tue, 4 Jun 2002 06:32:37 -0700 (PDT) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 4 Jun 2002 06:30:03 -0700 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 04 Jun 2002 19:22:18 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g54DVEt31051; Tue, 4 Jun 2002 19:01:14 +0530 Reply-To: From: "Rayapureddi Ramesh" To: "ISISWG (E-mail)" Cc: "ISIS (E-mail)" Message-Id: <002701c20bcd$ff6b79b0$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C20BFC.1923B5B0" X-OriginalArrivalTime: 04 Jun 2002 13:30:03.0560 (UTC) FILETIME=[EEFCB280:01C20BCB] Subject: [Isis-wg] reg: no of IS's in an area Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Jun 2002 19:14:48 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C20BFC.1923B5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, Is there any limitation on maximum number of Intermediate System can be configured in an Area. If any one knows please let me know. Thanks in advance. Regards, Ramesh *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0028_01C20BFC.1923B5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Is = there any=20 limitation on maximum number of Intermediate System can be = configured in an=20 Area.
If any = one knows=20 please let me know.
 
Thanks = in=20 advance.
 
Regards,
Ramesh
 
 
------=_NextPart_000_0028_01C20BFC.1923B5B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 11:05:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01885 for ; Tue, 4 Jun 2002 11:05:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54Ehpt14314; Tue, 4 Jun 2002 07:43:51 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54EVnt14209 for ; Tue, 4 Jun 2002 07:31:49 -0700 (PDT) (envelope-from jparker@axiowave.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g54EnTn91290 for ; Tue, 4 Jun 2002 07:49:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 4 Jun 2002 07:40:44 -0700 Message-ID: From: Jeff Parker To: "'rameshrr@future.futsoft.com'" , "ISISWG (E-mail)" Cc: "ISIS (E-mail)" Subject: RE: [Isis-wg] reg: no of IS's in an area MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Jun 2002 14:40:45.0406 (UTC) FILETIME=[CF5307E0:01C20BD5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Jun 2002 10:41:50 -0400 > Is there any limitation on maximum number of > Intermediate System can be configured in an Area. > If any one knows please let me know. > > Ramesh The protocol does not have any realistic hard limits. That is, you cannot have more than 2^48 routers in your network, but things will probably fall apart before reaching that limit. Implementations have limits: often these will be in the SPF computation, the processing of large LSP sets, and dealing with many interfaces. Various three digit numbers have been suggested as the realistic limits on the number of routers per area. Your mileage may vary. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 13:54:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07764 for ; Tue, 4 Jun 2002 13:54:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54HW8t15180; Tue, 4 Jun 2002 10:32:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54HFrt15093 for ; Tue, 4 Jun 2002 10:15:53 -0700 (PDT) (envelope-from jonathan.sadler@tellabs.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g54HXZn95851 for ; Tue, 4 Jun 2002 10:33:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from mx4.tellabs.com ([204.68.180.54]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 4 Jun 2002 10:31:08 -0700 Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint) with ESMTP id AHC55139; Tue, 4 Jun 2002 12:32:40 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-24.lisle.tellabs.com [172.23.111.24]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id MAA05143; Tue, 4 Jun 2002 12:32:40 -0500 (CDT) Message-ID: <3CFCF9B7.6C16D8D4@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "'rameshrr@future.futsoft.com'" , "ISISWG (E-mail)" , "ISIS (E-mail)" Subject: Re: [Isis-wg] reg: no of IS's in an area References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2002 17:31:08.0828 (UTC) FILETIME=[9CF56DC0:01C20BED] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 04 Jun 2002 12:32:39 -0500 Content-Transfer-Encoding: 7bit Please be aware that a number of IS-IS implementations used in the support of OSI CLNP routing are limited to 50 or so ISes per area. This situation exists due to advice provided by SIF to the SONET/SDH NE community back in the early '90s. While this doesn't pose an interoperability problem per se, it does cause nightmares for SONET/SDH DCN designers. Jonathan Sadler Jeff Parker wrote: > > > Is there any limitation on maximum number of > > Intermediate System can be configured in an Area. > > If any one knows please let me know. > > > > Ramesh > > The protocol does not have any realistic hard limits. > That is, you cannot have more than 2^48 routers in > your network, but things will probably fall apart > before reaching that limit. > > Implementations have limits: often these will be in > the SPF computation, the processing of large LSP sets, > and dealing with many interfaces. Various three digit > numbers have been suggested as the realistic limits > on the number of routers per area. Your mileage may vary. > > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jun 4 16:13:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13430 for ; Tue, 4 Jun 2002 16:13:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54Jp8t15873; Tue, 4 Jun 2002 12:51:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54JWet15782 for ; Tue, 4 Jun 2002 12:32:40 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g54JoMX32607 for ; Tue, 4 Jun 2002 12:50:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 4 Jun 2002 12:41:06 -0700 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g54JhBk1020641; Tue, 4 Jun 2002 15:43:11 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-133.cisco.com [64.102.83.133]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABP25080; Tue, 4 Jun 2002 15:42:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20020604151606.01a8dd18@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: jonathan.sadler@tellabs.com From: Jeff Learman Subject: Re: [Isis-wg] reg: no of IS's in an area Cc: "ISISWG (E-mail)" In-Reply-To: <3CFCF9B7.6C16D8D4@tellabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 04 Jun 2002 19:41:06.0685 (UTC) FILETIME=[C4D7FAD0:01C20BFF] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 04 Jun 2002 15:42:13 -0400 The limit of 50 (in the Guidelines doc written in 1997) was advice to network designers based on limitations of existing equipment. It's unfortunate if some NE vendors have misconstrued that as an excuse to limit their support to 50. Regards, Jeff At 01:32 PM 6/4/2002, Jonathan Sadler wrote: >Please be aware that a number of IS-IS implementations used in the >support of OSI CLNP routing are limited to 50 or so ISes per area. This >situation exists due to advice provided by SIF to the SONET/SDH NE >community back in the early '90s. > >While this doesn't pose an interoperability problem per se, it does >cause nightmares for SONET/SDH DCN designers. > >Jonathan Sadler > >Jeff Parker wrote: >> >> > Is there any limitation on maximum number of >> > Intermediate System can be configured in an Area. >> > If any one knows please let me know. >> > >> > Ramesh >> >> The protocol does not have any realistic hard limits. >> That is, you cannot have more than 2^48 routers in >> your network, but things will probably fall apart >> before reaching that limit. >> >> Implementations have limits: often these will be in >> the SPF computation, the processing of large LSP sets, >> and dealing with many interfaces. Various three digit >> numbers have been suggested as the realistic limits >> on the number of routers per area. Your mileage may vary. >> >> - jeff parker >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@spider.juniper.net >> http://spider.juniper.net/mailman/listinfo/isis-wg >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the >reader of this message is not the intended recipient, or an >employee or agent responsible for delivering this message to >the intended recipient, you are hereby notified that any >reproduction, dissemination or distribution of this >communication is strictly prohibited. If you have received >this communication in error, please notify us immediately by >replying to the message and deleting it from your computer. > >Thank you. >Tellabs >============================================================ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 9 10:26:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01607 for ; Sun, 9 Jun 2002 10:26:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g59E1tt52190; Sun, 9 Jun 2002 07:01:55 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54MHWt16575 for ; Tue, 4 Jun 2002 15:17:32 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: IS-IS MIB (metric comments) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Jun 2002 18:35:07 -0400 > In version 0.8 of the ISIS MIB, you have a Textual Convention > for DefaultMetric which is defined as (1..63). Should we > allow zero in the range, as our passive interfaces have a > metric of zero. > > Also, are you working on adding a WideMetric TC and associated > objects (isisCircLevelWideMetric, isisIPRAWideMetric, > isisSummAddrWideMetric)? > > -don Don - 1) Thanks. The TC is easy to change from 1..63 to 0..63. 2) I'm not sure if the right thing to do here is to add new types. Is there harm in simply extending the range of all of these to go past 63? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 9 12:23:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04966 for ; Sun, 9 Jun 2002 12:23:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g59Fxrt52747; Sun, 9 Jun 2002 08:59:53 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xmxpita.excite.com (nat1.excitenetwork.com [63.236.75.3]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g54Mn9t16726 for ; Tue, 4 Jun 2002 15:49:10 -0700 (PDT) (envelope-from dgoodspe@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id B62D9B6FE; Tue, 4 Jun 2002 19:06:47 -0400 (EDT) To: jparker@axiowave.com, dgoodspe@excite.com Received: from [63.104.212.252] by xprdmailfe20.nwk.excite.com via HTTP; Tue, 04 Jun 2002 19:06:47 EST Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: isis-wg@spider.juniper.net Message-Id: <20020604230647.B62D9B6FE@xmxpita.excite.com> Subject: [Isis-wg] RE: IS-IS MIB (metric comments) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Jun 2002 19:06:47 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff, Thanks for cc'ing the WG on this. I'd forgotten to when I sent this originally. In section 12.2 of the "Recommendations" draft you just sent out, we acknowledge that the narrow and the wide metric can be set independently. Separate attributes would make sense then, even if the IS-IS implementation used always sets one equal to the other internally. I would also push for a separate WideMetric TC since allowing a larger range on the current DefaultMetric attributes might break some range checking algorithms. My 2 cents, Don --- On Tue 06/04, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com Cc: isis-wg@spider.juniper.net Date: Tue 06/04 Subject: RE: IS-IS MIB (metric comments) > > > In version 0.8 of the ISIS MIB, you have a Textual Convention > > for DefaultMetric which is defined as (1..63). Should we > > allow zero in the range, as our passive interfaces have a > > metric of zero. > > > > Also, are you working on adding a WideMetric TC and associated > > objects (isisCircLevelWideMetric, isisIPRAWideMetric, > > isisSummAddrWideMetric)? > > > > -don > > Don - > 1) Thanks. The TC is easy to change from 1..63 to 0..63. > > 2) I'm not sure if the right thing to do here is to add > new types. Is there harm in simply extending the range of > all of these to go past 63? > > - jeff parker > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 9 15:12:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06545 for ; Sun, 9 Jun 2002 15:12:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g59ImSt53690; Sun, 9 Jun 2002 11:48:28 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g55BRkt20766 for ; Wed, 5 Jun 2002 04:27:46 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g55BjXn15668 for ; Wed, 5 Jun 2002 04:45:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from zctfs063.europe.nortel.com ([47.164.128.120]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 5 Jun 2002 04:41:08 -0700 Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g55Bgfj06995; Wed, 5 Jun 2002 13:42:41 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g55Bgc505531; Wed, 5 Jun 2002 12:42:39 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 12:42:44 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB6F5@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Alex Zinin'" , Amir Hermelin Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C85.7758C92A" X-OriginalArrivalTime: 05 Jun 2002 11:41:08.0781 (UTC) FILETIME=[E25E4DD0:01C20C85] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 5 Jun 2002 12:42:41 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20C85.7758C92A Content-Type: text/plain; charset="iso-8859-1" > ... > >> > Extended system-id > >> > >> Sounds like we're stretching out the normal system-id. > >> Maybe "Virtual system-id" would be a better choice? > >> > > > again, could be bad naming. However, I originally thought > "Virtual" to be a little confusing, > > as a "virtual link" term is already used in the IS-IS spec, > for a completely different purpose. The > > draft uses "extended" for LSPs, since they really extend > the original LS information an IS could advertise, > > as opposed to "Virtual System", which doesn't really add > any additional info. Does that > > make sense? > > "extended" LSPs, though not perfect, make more sense--I couldn't come > up with a better name, maybe native English speakers can :) > > Is this is a similar concept to "Extended Local Circuit ID" in three way handshaking? it sounds as though it is, in which case consistency is a good thing. Philip ------_=_NextPart_001_01C20C85.7758C92A Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ...

> ...
> >> >      Extended system-id
> >>
> >> Sounds like we're stretching out the normal system-id.
> >> Maybe "Virtual system-id" would be a better choice?
> >>
>
> > again, could be bad naming. However, I originally thought
> "Virtual" to be a little confusing,
> > as a "virtual link" term is already used in the IS-IS spec,
> for a completely different purpose. The
> > draft uses "extended" for LSPs, since they really extend
> the original LS information an IS could advertise,
> > as opposed to "Virtual System", which doesn't really add
> any additional info. Does that
> > make sense?
>
> "extended" LSPs, though not perfect, make more sense--I couldn't come
> up with a better name, maybe native English speakers can :)
>
>

Is this is a similar concept to "Extended Local Circuit ID" in three way handshaking?
it sounds as though it is, in which case consistency is a good thing.

Philip

------_=_NextPart_001_01C20C85.7758C92A-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 9 16:57:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07498 for ; Sun, 9 Jun 2002 16:57:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g59KXCt54273; Sun, 9 Jun 2002 13:33:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from psg.com (psg.com [147.28.0.62]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4P1Ikt33859 for ; Fri, 24 May 2002 18:18:46 -0700 (PDT) (envelope-from zinin@psg.com) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17BQSm-000MDC-00 for isis-wg@spider.juniper.net; Fri, 24 May 2002 18:35:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4911805270.20020524183350@psg.com> To: isis-wg@spider.juniper.net Subject: Fwd: Re: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 May 2002 18:33:50 -0700 Content-Transfer-Encoding: 7bit Haven't seen this getting through to the list for some reason... This is a forwarded message From: Alex Zinin To: isis-wg@juniper.net Cc: Date: Thursday, May 23, 2002, 7:25:01 PM Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... ===8<==============Original message text=============== Sorry I'm one day late with the comments. > Status ... > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [BCP14]. Pls, move this somewhere within the document (not the Abstract, though, probably the Intro). Also, please go through the text and make sure all occurrences of must/should/may/etc are capitalized when used to express the requirements level. > 1. Introduction > ... > A number of factors can contribute to exceeding this limit: ... > - The growing size of route tables and AS topologies. The size of the RT contributes to the LSP size in case of redistribution and inter-level propagation mentioned in the following item. Here you probably mean the increasing number of destinations (amount of reachability info) to be distributed. > 1.1 Definitions of Commonly Used Terms > > This section provides definitions for terms that are used throughout > the text. > > Originating System > A router running the IS-IS protocol. The term hints there should be some words about LSP origination here. > Original system-id > The system-id of an Originating System. Isn't this supposed to be the "normal" system-id (as opposed to the additional ones)? I mean you should explain what is "original" about it. > Extended system-id Sounds like we're stretching out the normal system-id. Maybe "Virtual system-id" would be a better choice? ... > > Extended LSP > An LSP using an extended system-id in its LSP ID. Same comment about "extended". > 1.2 Operation Modes > > Two administrative operation modes are provided: .. > > These modes may be configured per level. There is no restriction > that an L1/L2 IS operates in the same mode, for both L1 and L2. Shouldn't the modes be on a per-level & area basis. This text also sounds like all routers within a level (or an area if corrected) need to work in the same mode, which is not true, since modified SPF is a requirement regardless of the LSP origination mode. > 2.0 IS Alias ID TLV (IS-A) > > The proposed IS-A TLV allows extension-capable ISs to recognize all > LSPs of an Originating System, and combine the original and extended > LSPs for the purpose of SPF computation. > > The IS Alias ID TLV is type 24, and contains a new data structure, > consisting of: > 7 octets of system Id and pseudonode number > 1 octet of length of sub-TLVs > 0-247 octets of sub-TLVs, > where each sub-TLV consists of a sequence of > 1 octet of sub-type > 1 octet of length > 0-245 octets of value > > Without sub-TLVs, this structure consumes 8 octets per LSP set. This > TLV MUST be included in fragment 0 of every LSP set belonging to an > Originating System. Couldn't find any info on how to put S' and S'' in the TLV. Couldn't find description of any sub-TLVs that would be used to do the above. Couldn't find any rules about sub-TLV handling, i.e., padding and length calculation with it. The format description above should use the illustration style from 1195. > 3.1 Both Operation Modes > > Under both modes, the Originating System MUST include information > binding the Original LSP and the Extended ones. It can do this since > it is trivially an extension-capable IS. This is to ensure other > routers correctly process the extra information in their SPF ^ "implementing this specification" or something like this > 3.1.1 The Attached Bits ... > 3.1.2 The Partition Repair Bit What about the OL bit? > 3.2 Operation Mode 1 Additions ... > When an extended LSP belonging to extended system-id S' is first > created, the original LSP MUST specify S' as a neighbor, with metric > set to zero. This in order to satisfy the two-way connectivity check > on other routers, as well as to consider the cost of reaching the I thought that the S'->S link would be needed to satisfy the TWC check for the S->S' one, not the other way around... > 4. Purging Extended LSP Fragments ... > However, an extended LSP fragment zero should not > be purged until all of the fragments in its set (i.e. belonging to a > particular extended system-id), are empty as well. This is to ensure > implementations consider the fragments in their SPF computations, as > specified in section 7.2.5. Given what section 5 says about ignoring non-0 fragments when fragment zero is missing, what does the above rule give us? > 5. Modifications to LSP handling in SPF ... > If LSP fragment 0 of the original LSP set is missing, all of the LSPs > generated by that Originating System (extended as well) MUST NOT be > considered in the SPF. That is, the large logical LSP isn't > considered in the SPF. If an LSP fragment 0 of an extended LSP set > is missing, only that LSP set MUST NOT be considered in the SPF. This text should also say that fragment 0's RemainingLifetime should be > 0 > 7. Interoperating between extension-capable and non-extension-capable > ISs. ... > It is possible to transition a live network, using the following > steps: > - Upgrade the routers, one-by-one, to run this extension in > Operation Mode 1. The other non-extension-capable routers will > interoperate correctly. > - When all routers are extension-capable, configure them one-by-one > to run in Operation Mode 2. All extension-capable routers > interoperate correctly, regardless of what mode they're run in. We don't have to go through mode-1 to get to mode-2. An upgrade of SW does not necessarily mean changing the LSP origination process. In fact, I would argue that the default setting MUST be the standard one, i.e., neither mode 1 nor mode 2, and it would be really great if this was spelled out. > 9. Acknowledgments > > The author would like to thank Tony Li and Radia Perlman for helpful ^"s" > comments and suggestions on the subject. > 10. References ... > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. > Przygienda Unused ref. Check if you have others. > 11. Authors' Address ^"es" Alex ===8<===========End of original message text=========== -- Alex _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 10 06:37:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27386 for ; Mon, 10 Jun 2002 06:37:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AAE0t58467; Mon, 10 Jun 2002 03:14:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AABLt58441 for ; Mon, 10 Jun 2002 03:11:21 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AATVV19075 for ; Mon, 10 Jun 2002 12:29:31 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AATTk10374 for ; Mon, 10 Jun 2002 11:29:30 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 11:29:41 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB701@zhard0jd.europe.nortel.com> From: "Philip Christian" To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21069.BADDA0D4" Subject: [Isis-wg] Proprietary / Private TLV numbers? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 11:29:41 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21069.BADDA0D4 Content-Type: text/plain; charset="iso-8859-1" Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is not really any mechanism for private or proprietary use of a TLV. Thus various companies (including my own) have just pcked one and used it for their own purpose. Eventually this will create an interop problem, but what else is a company to do? Is there a way that we could define that a certain TLV number is for private / proprietary / experimental purposes? This would then stop people just picking one. I am thinking that there would have to be some sort of entity identifier in there so that when you see this TLV you know whether it is yours or not. Maybe we could define that the first four bytes are an IP address for example. Any entity large enough to want to use a proprietary TLV would have a public IP address to put in there, I would have thought. After the first for bytes then the rest would be free. Or maybe there is a better way to identify a particular company / entity (like a MAC address)? Maybe ISO 8348? What do people think? Philip ------_=_NextPart_001_01C21069.BADDA0D4 Content-Type: text/html; charset="iso-8859-1"
Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is not really any mechanism for private or proprietary use of a TLV.
 
Thus various companies (including my own) have just pcked one and used it for their own purpose.  Eventually this will create an interop problem, but what else is a company to do?
 
Is there a way that we could define that a certain TLV number is for private / proprietary / experimental purposes?
 
This would then stop people just picking one.
 
I am thinking that there would have to be some sort of entity identifier in there so that when you see this TLV you know whether it is yours or not.
 
Maybe we could define that the first four bytes are an IP address for example.  Any entity large enough to want to use a proprietary TLV would have a public IP address to put in there, I would have thought. After the first for bytes then the rest would be free.
 
Or maybe there is a better way to identify a particular company / entity (like a MAC address)?  Maybe ISO 8348?
 
What do people think?
 
Philip
 
------_=_NextPart_001_01C21069.BADDA0D4-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 10 07:43:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29409 for ; Mon, 10 Jun 2002 07:43:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ABK1t58787; Mon, 10 Jun 2002 04:20:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AB8ct58729 for ; Mon, 10 Jun 2002 04:08:39 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp92.cisco.com [10.50.0.91]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA29888; Mon, 10 Jun 2002 12:26:43 +0100 (BST) Message-Id: <4.3.2.7.2.20020610121359.026459d8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? Cc: isis-wg@spider.juniper.net In-Reply-To: <4103264BC8D3D51180B7002048400C454FB701@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 12:23:39 +0100 At 11:29 10/06/2002 +0100, Philip Christian wrote: >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is >not really any mechanism for private or proprietary use of a TLV. > >Thus various companies (including my own) have just pcked one and used it >for their own purpose. Eventually this will create an interop problem, >but what else is a company to do? > >Is there a way that we could define that a certain TLV number is for >private / proprietary / experimental purposes? > >This would then stop people just picking one. > >I am thinking that there would have to be some sort of entity identifier >in there so that when you see this TLV you know whether it is yours or not. > >Maybe we could define that the first four bytes are an IP address for >example. Any entity large enough to want to use a proprietary TLV would >have a public IP address to put in there, I would have thought. After the >first for bytes then the rest would be free. > >Or maybe there is a better way to identify a particular company / entity >(like a MAC address)? Maybe ISO 8348? > >What do people think? > >Philip > This has been suggested before, but never came to anything. I think if it WERE to be done then using something link the MAC OUI would probably work. What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) Mike _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 10 08:57:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01939 for ; Mon, 10 Jun 2002 08:57:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ACY4t59142; Mon, 10 Jun 2002 05:34:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ACOwt59083 for ; Mon, 10 Jun 2002 05:24:58 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5ACh8I12811; Mon, 10 Jun 2002 14:43:08 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5ACh6j17734; Mon, 10 Jun 2002 13:43:06 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 13:43:18 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB702@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'mike shand'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2107C.658C0C02" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 13:43:18 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2107C.658C0C02 Content-Type: text/plain; charset="iso-8859-1" I suppose that we could define different sub-TLVs, a sub-TLV if the identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc Then folks could use whichever mechanism they prefer, as long as it is a globally unique identifier. Or is that too complex? Philip > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Monday, June 10, 2002 12:24 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > that there is > >not really any mechanism for private or proprietary use of a TLV. > > > >Thus various companies (including my own) have just pcked > one and used it > >for their own purpose. Eventually this will create an > interop problem, > >but what else is a company to do? > > > >Is there a way that we could define that a certain TLV number is for > >private / proprietary / experimental purposes? > > > >This would then stop people just picking one. > > > >I am thinking that there would have to be some sort of > entity identifier > >in there so that when you see this TLV you know whether it > is yours or not. > > > >Maybe we could define that the first four bytes are an IP > address for > >example. Any entity large enough to want to use a > proprietary TLV would > >have a public IP address to put in there, I would have > thought. After the > >first for bytes then the rest would be free. > > > >Or maybe there is a better way to identify a particular > company / entity > >(like a MAC address)? Maybe ISO 8348? > > > >What do people think? > > > >Philip > > > > This has been suggested before, but never came to anything. I > think if it > WERE to be done then using something link the MAC OUI would > probably work. > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > Mike > ------_=_NextPart_001_01C2107C.658C0C02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I suppose that we could define different sub-TLVs, a = sub-TLV if the identifier is an IPv4 address, a different sub-TLV if it = is a MAC address, etc

Then folks could use whichever mechanism they prefer, = as long as it is a globally unique identifier.

Or is that too complex?

Philip

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Monday, June 10, 2002 12:24 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> At 11:29 10/06/2002 +0100, Philip Christian = wrote:
> >Looking at = draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> that there is
> >not really any mechanism for private or = proprietary use of a TLV.
> >
> >Thus various companies (including my own) = have just pcked
> one and used it
> >for their own purpose.  Eventually = this will create an
> interop problem,
> >but what else is a company to do?
> >
> >Is there a way that we could define that a = certain TLV number is for
> >private / proprietary / experimental = purposes?
> >
> >This would then stop people just picking = one.
> >
> >I am thinking that there would have to be = some sort of
> entity identifier
> >in there so that when you see this TLV you = know whether it
> is yours or not.
> >
> >Maybe we could define that the first four = bytes are an IP
> address for
> >example.  Any entity large enough to = want to use a
> proprietary TLV would
> >have a public IP address to put in there, I = would have
> thought. After the
> >first for bytes then the rest would be = free.
> >
> >Or maybe there is a better way to identify = a particular
> company / entity
> >(like a MAC address)?  Maybe ISO = 8348?
> >
> >What do people think?
> >
> >Philip
> >
>
> This has been suggested before, but never came = to anything. I
> think if it
> WERE to be done then using something link the = MAC OUI would
> probably work.
> What do you mean by ISO 8348? Do you mean ISO = 6523? I hope not :-)
>
>          = Mike
>

------_=_NextPart_001_01C2107C.658C0C02-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 10 09:26:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03004 for ; Mon, 10 Jun 2002 09:26:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AD2vt59309; Mon, 10 Jun 2002 06:02:57 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AClFt59212 for ; Mon, 10 Jun 2002 05:47:16 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp92.cisco.com [10.50.0.91]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA03187; Mon, 10 Jun 2002 14:05:24 +0100 (BST) Message-Id: <4.3.2.7.2.20020610140439.02656f28@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? Cc: isis-wg@spider.juniper.net In-Reply-To: <4103264BC8D3D51180B7002048400C454FB702@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 14:05:20 +0100 At 13:43 10/06/2002 +0100, Philip Christian wrote: >I suppose that we could define different sub-TLVs, a sub-TLV if the >identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc > >Then folks could use whichever mechanism they prefer, as long as it is a >globally unique identifier. > >Or is that too complex? Yes! That's how NSAP addresses got to be so awful :-) Mike >Philip > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Monday, June 10, 2002 12:24 PM > > To: Christian, Philip [HAL02:GI50:EXCH] > > Cc: isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > that there is > > >not really any mechanism for private or proprietary use of a TLV. > > > > > >Thus various companies (including my own) have just pcked > > one and used it > > >for their own purpose. Eventually this will create an > > interop problem, > > >but what else is a company to do? > > > > > >Is there a way that we could define that a certain TLV number is for > > >private / proprietary / experimental purposes? > > > > > >This would then stop people just picking one. > > > > > >I am thinking that there would have to be some sort of > > entity identifier > > >in there so that when you see this TLV you know whether it > > is yours or not. > > > > > >Maybe we could define that the first four bytes are an IP > > address for > > >example. Any entity large enough to want to use a > > proprietary TLV would > > >have a public IP address to put in there, I would have > > thought. After the > > >first for bytes then the rest would be free. > > > > > >Or maybe there is a better way to identify a particular > > company / entity > > >(like a MAC address)? Maybe ISO 8348? > > > > > >What do people think? > > > > > >Philip > > > > > > > This has been suggested before, but never came to anything. I > > think if it > > WERE to be done then using something link the MAC OUI would > > probably work. > > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > > > Mike > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 10 10:42:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06436 for ; Mon, 10 Jun 2002 10:42:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AEIBt59723; Mon, 10 Jun 2002 07:18:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ADmpt59588 for ; Mon, 10 Jun 2002 06:48:52 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AE72B01426; Mon, 10 Jun 2002 16:07:03 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AE71j20705; Mon, 10 Jun 2002 15:07:01 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 15:07:00 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Mike Truskowski'" , mshand@cisco.com Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21088.155172F2" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 15:06:57 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21088.155172F2 Content-Type: text/plain; charset="iso-8859-1" A vendor code of 4 octets could be an IPv4 address. Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has. Even the smallest vendor can buy a /32 IP address for this purpose. That would work. Philip > -----Original Message----- > From: Mike Truskowski [mailto:truskows@cisco.com] > Sent: Monday, June 10, 2002 2:42 PM > To: mshand@cisco.com > Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > Why not just do the following? > > +-------------------------------------------------+ > | Type | Length | Value | > +-------------------------------------------------+ > | TLV # | Length | vendor code | "value" | > +-------------------------------------------------+ > > Where the vendor code is a fixed 3-4 octets? > > I guess one could do this on their own... couldn't they? > > The major problem I see here is what Philip said he wanted to fix... > > If vendors are doing this already and this is trying to avoid > interoperability > problems... then it would seem reasonable that the carrier > would go back and > install new images or force the vendor to fix the embedded > base.. but they > won't do either.. thus leaving the problem to stumble over some day... > > Mike > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > >I suppose that we could define different sub-TLVs, a > sub-TLV if the > > >identifier is an IPv4 address, a different sub-TLV if it > is a MAC address, etc > > > > > >Then folks could use whichever mechanism they prefer, as > long as it is a > > >globally unique identifier. > > > > > >Or is that too complex? > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > Mike > > > > > > > > >Philip > > > > > > > -----Original Message----- > > > > From: mike shand > [mailto:mshand@cisco.com] > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > Cc: isis-wg@spider.juniper.net > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > that there is > > > > >not really any mechanism for private or proprietary > use of a TLV. > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > one and used it > > > > >for their own purpose. Eventually this will create an > > > > interop problem, > > > > >but what else is a company to do? > > > > > > > > > >Is there a way that we could define that a certain TLV > number is for > > > > >private / proprietary / experimental purposes? > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > >I am thinking that there would have to be some sort of > > > > entity identifier > > > > >in there so that when you see this TLV you know whether it > > > > is yours or not. > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > address for > > > > >example. Any entity large enough to want to use a > > > > proprietary TLV would > > > > >have a public IP address to put in there, I would have > > > > thought. After the > > > > >first for bytes then the rest would be free. > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > company / entity > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > >What do people think? > > > > > > > > > >Philip > > > > > > > > > > > > > This has been suggested before, but never came to anything. I > > > > think if it > > > > WERE to be done then using something link the MAC OUI would > > > > probably work. > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > hope not :-) > > > > > > > > Mike > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > ------_=_NextPart_001_01C21088.155172F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

A vendor code of 4 octets could be an IPv4 = address.
Then no-one would have to assign them. The vendor = just uses a global IPv4 address that he has.

Even the smallest vendor can buy a /32 IP address for = this purpose.

That would work.

Philip

> -----Original Message-----
> From: Mike Truskowski [mailto:truskows@cisco.com]=
> Sent: Monday, June 10, 2002 2:42 PM
> To: mshand@cisco.com
> Cc: Christian, Philip [HAL02:GI50:EXCH]; = isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> Why not just do the following?
>
> = +-------------------------------------------------+
> | Type   |  Length  = |       = Value           &= nbsp;     |
> = +-------------------------------------------------+
> | TLV #  |  Length  |  = vendor code  |   "value"   |
> = +-------------------------------------------------+
>
> Where the vendor code is a fixed 3-4 = octets?
>
> I guess one could do this on their own... = couldn't they?
>
> The major problem I see here is what Philip = said he wanted to fix...
>
> If vendors are doing this already and this is = trying to avoid
> interoperability
> problems... then it would seem reasonable that = the carrier
> would go back and
> install new images or force the vendor to fix = the embedded
> base..  but they
> won't do either.. thus leaving the problem to = stumble over some day...
>
> Mike
>
> > At 13:43 10/06/2002 +0100, Philip = Christian wrote:
> >
> > >I suppose that we could define = different sub-TLVs, a
> sub-TLV if the
> > >identifier is an IPv4 address, a = different sub-TLV if it
> is a MAC address, etc
> > >
> > >Then folks could use whichever = mechanism they prefer, as
> long as it is a
> > >globally unique identifier.
> > >
> > >Or is that too complex?
> >
> > Yes! That's how NSAP addresses got to be = so awful :-)
> >
> = >          Mike
> >
> >
> >
> > >Philip
> > >
> > > > -----Original = Message-----
> > > > From: mike shand
> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com]
> > > > Sent: Monday, June 10, 2002 = 12:24 PM
> > > > To: Christian, Philip = [HAL02:GI50:EXCH]
> > > > Cc: = isis-wg@spider.juniper.net
> > > > Subject: Re: [Isis-wg] = Proprietary / Private TLV numbers?
> > > >
> > > >
> > > > At 11:29 10/06/2002 +0100, = Philip Christian wrote:
> > > > >Looking at = draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> > > > that there is
> > > > >not really any mechanism for = private or proprietary
> use of a TLV.
> > > > >
> > > > >Thus various companies = (including my own) have just pcked
> > > > one and used it
> > > > >for their own purpose.  = Eventually this will create an
> > > > interop problem,
> > > > >but what else is a company = to do?
> > > > >
> > > > >Is there a way that we could = define that a certain TLV
> number is for
> > > > >private / proprietary / = experimental purposes?
> > > > >
> > > > >This would then stop people = just picking one.
> > > > >
> > > > >I am thinking that there = would have to be some sort of
> > > > entity identifier
> > > > >in there so that when you = see this TLV you know whether it
> > > > is yours or not.
> > > > >
> > > > >Maybe we could define that = the first four bytes are an IP
> > > > address for
> > > > >example.  Any entity = large enough to want to use a
> > > > proprietary TLV would
> > > > >have a public IP address to = put in there, I would have
> > > > thought. After the
> > > > >first for bytes then the = rest would be free.
> > > > >
> > > > >Or maybe there is a better = way to identify a particular
> > > > company / entity
> > > > >(like a MAC address)?  = Maybe ISO 8348?
> > > > >
> > > > >What do people think?
> > > > >
> > > > >Philip
> > > > >
> > > >
> > > > This has been suggested before, = but never came to anything. I
> > > > think if it
> > > > WERE to be done then using = something link the MAC OUI would
> > > > probably work.
> > > > What do you mean by ISO 8348? Do = you mean ISO 6523? I
> hope not :-)
> > > >
> > > = >          Mike
> > > >
> >
> > = _______________________________________________
> > Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> > http://spider.juniper.net/mailman/listinfo/isis-wg=
> >
>
>

------_=_NextPart_001_01C21088.155172F2-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jun 12 08:58:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26266 for ; Wed, 12 Jun 2002 08:58:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5CCYXt73010; Wed, 12 Jun 2002 05:34:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5CCGKt72906 for ; Wed, 12 Jun 2002 05:16:21 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CCXju09662; Wed, 12 Jun 2002 14:33:46 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CCXhS12037; Wed, 12 Jun 2002 13:33:43 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:33:51 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nortel.com> From: "Philip Christian" To: isis-wg@spider.juniper.net Cc: "'Tony Przygienda'" , "'Mike Truskowski'" , "'mike shand'" Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2120C.FEB807FA" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 12 Jun 2002 13:33:43 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2120C.FEB807FA Content-Type: text/plain; charset="iso-8859-1" I have done an update, see below Philip > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Tuesday, June 11, 2002 3:56 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski' > Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? > > > At 15:38 11/06/2002 +0100, Philip Christian wrote: > >On receipt of an LSP a router MUST ignore TLVs of type XXX that > > include an OUI from a different organization, > > MUST is a bit strong here. SHOULD or MAY, perhaps. If you > know how to parse > company X's subTLVs you should be allowed to do so. > > I'm not sure we want to get into mentioning non-standard OUIs > with G or L > bits set. > > Mike > > Internet Engineering Task Force P. Christian INTERNET DRAFT Nortel Networks June 2002 TLV for Proprietary Use draft-ietf-isis-private-tlv-forlist2.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. 1. Abstract This document defines a TLV that may be used for vendor specific or experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. TLV for Proprietary Use June 2002 3. Introduction IS-IS as defined in [1] has always been an extensible routing protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] has always defined that an IS-IS router SHALL flood entire LSPs that it receives on to other IS-IS routers in the network, whether or not it understands the TLVs that are included in the LSP. Also IS-IS LSPs are structured such that a router can find TLVs that it understands, whilst ignoring ones that it does not. Thus information that is encoded into a TLV and placed into an LSP by a router will be propagated to every other router in an IS-IS level-1 area or level-2 subdomain. The basic function of an IS-IS TLV is identified by the first byte of the TLV. Thus there are only 256 possible basic types of TLV. Certain types of TLV have been defined to include sub-TLVs so that a single TLV type can be used for multiple functions. No single authority assigns TLV type numbers, [2] lists all known TLV type numbers at this time. Also no TLV type number was ever defined for private, proprietary or experimental use. The extensible nature of IS-IS has made the use of TLVs in LSPs for proprietary purposes so useful that in the absence of a central authority for assigning TLV type numbers vendors have occasionally simply chosen a number and hoped for the best. The risk is that such a TLV type number may then be chosen by another organization at a later time for a different function, thus creating an interoperability problem. Also this accelerates the burning of the 256 possible TLV type numbers. This document specifies a TLV type number that may be used for proprietary, private or experimental purposes, and a mechanism that insures that implementations from different sources can use the TLV for different purposes in the same network without creating interoperability problems. By using this new TLV, companies, individuals or institutions may use extensions to IS-IS without fear of interoperability problems with other organizations in the future, and the available pool of TLV type numbers will no longer be diminished by proprietary use. 4. TLV type number for proprietary use The type field for this TLV SHALL be XXX. TLVs that use XXX for the type field MUST include a valid IEEE assigned OUI as the first three bytes of the value field of the TLV. For more information about OUIs see [3]. TLV for Proprietary Use June 2002 On receipt of an LSP a router MAY ignore TLVs of type XXX that include an OUI from a different organization, however the router MUST flood the LSP onwards as per [1]. After the first three bytes of the value field subsequent bytes may be used freely for any purpose provided that the resultant TLV is conformant with [1]. Many organizations will have access to only one or a few OUIs. Implementers are free to format the value field after their OUI into sub-TLVs so that it may be used for multiple purposes, and would be well advised to do this from the outset. Note that if sub-TLVs are to be used then the very first implementation to exist will need to recognize the sub-TLV structure, and ignore sub-TLVs that it does not understand whilst searching for sub-TLVs that it does understand. 5. Security Considerations The proprietary TLV raises no new security issues for IS-IS. Information placed in an IS-IS TLV cannot be considered secure, and so if security is required then an implementation will need to encrypt the information using a suitable method. 6. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992. [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV Codepoints in ISIS, Tony Przygienda, November 2001 [3] http://standards.ieee.org/regauth/oui/index.html 7. Acknowledgments The author takes no credit for this work as the concept was discussed in the IS-IS Working Group before the author even became an active participant. Suggestions for acknowledgement gladly received. 8. Author's Addresses Philip Christian Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: christi@nortelnetworks.com ------_=_NextPart_001_01C2120C.FEB807FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I have done an update, see below

Philip

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Tuesday, June 11, 2002 3:56 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Tony Przygienda'; = isis-wg@spider.juniper.net; 'Mike Truskowski'
> Subject: RE: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> At 15:38 11/06/2002 +0100, Philip Christian = wrote:
> >On receipt of an LSP a router MUST ignore = TLVs of type XXX that
> >    include an OUI from a = different organization,
>
> MUST is a bit strong here. SHOULD or MAY, = perhaps. If you
> know how to parse
> company X's subTLVs you should be allowed to do = so.
>
> I'm not sure we want to get into mentioning = non-standard OUIs
> with G or L
> bits set.
>
>          = Mike
>
>

Internet Engineering Task = Force           &= nbsp;           &= nbsp;    P. Christian
INTERNET = DRAFT           &= nbsp;           &= nbsp;           &= nbsp;      Nortel Networks
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   June 2002
 
 
          &nb= sp;           &nb= sp;   TLV for Proprietary Use
          &nb= sp;          = draft-ietf-isis-private-tlv-forlist2.txt
 
Status of this Memo
 
   This document is an Internet-Draft and = is in full conformance with
   all provisions of Section 10 of RFC = 2026.
   
   Internet Drafts are working documents = of the Internet Engineering
   Task Force (IETF), its Areas, and its = Working Groups.  Note that
   other groups may also distribute = working documents as Internet
   Drafts.
   
   Internet Drafts are draft documents = valid for a maximum of six
   months.  Internet Drafts may be = updated, replaced, or obsoleted by
   other documents at any time.  It = is not appropriate to use Internet
   Drafts as reference material or to cite = them other than as a
   "working draft" or "work = in progress".
   
   The list of current Internet-Drafts can = be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt =
   
   The list of Internet-Draft Shadow = Directories can be accessed at
   http://www.ietf.org/shadow.html.
   
   This memo provides information for the = Internet community. This memo
   does not specify an Internet standard = of any kind. 
   
   Distribution of this draft is = unlimited.
   
   
1. Abstract
   
   This document defines a TLV that may be = used for vendor specific or
   experimental extensions to the IS-IS = routing protocol, and defines
   the format of the TLV.
   
   
2. Conventions used in this document
   
   The key words "MUST", = "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
   "SHOULD", "SHOULD = NOT", "RECOMMENDED",  "MAY", and = "OPTIONAL" in
   this document are to be interpreted as = described in RFC 2119.
   





 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002 
 
3. Introduction
   
   IS-IS as defined in [1] has always been = an extensible routing
   protocol.  Extensions to IS-IS are = encoded as a TLV.  Critically [1]
   has always defined that an IS-IS router = SHALL flood entire LSPs that
   it receives on to other IS-IS routers = in the network, whether or not
   it understands the TLVs that are = included in the LSP.  Also IS-IS
   LSPs are structured such that a router = can find TLVs that it
   understands, whilst ignoring ones that = it does not.
   
   Thus information that is encoded into a = TLV and placed into an LSP
   by a router will be propagated to every = other router in an IS-IS
   level-1 area or level-2 subdomain. =
   
   The basic function of an IS-IS TLV is = identified by the first byte
   of the TLV.  Thus there are only = 256 possible basic types of TLV. 
   Certain types of TLV have been defined = to include sub-TLVs so that a
   single TLV type can be used for = multiple functions.
   
   No single authority assigns TLV type = numbers, [2] lists all known
   TLV type numbers at this time.  = Also no TLV type number was ever
   defined for private, proprietary or = experimental use.
   
   The extensible nature of IS-IS has made = the use of TLVs in LSPs for
   proprietary purposes so useful that in = the absence of a central
   authority for assigning TLV type = numbers vendors have occasionally
   simply chosen a number and hoped for = the best.  The risk is that
   such a TLV type number may then be = chosen by another organization at
   a later time for a different function, = thus creating an
   interoperability problem. Also this = accelerates the burning of the
   256 possible TLV type numbers.
   
   This document specifies a TLV type = number that may be used for
   proprietary, private or experimental = purposes, and a mechanism that
   insures that implementations from = different sources can use the TLV
   for different purposes in the same = network without creating
   interoperability problems.
   
   By using this new TLV, companies, = individuals or institutions may
   use extensions to IS-IS without fear of = interoperability problems
   with other organizations in the future, = and the available pool of
   TLV type numbers will no longer be = diminished by proprietary use.
   
4. TLV type number for proprietary use
   
   The type field for this TLV SHALL be = XXX.
   
   TLVs that use XXX for the type field = MUST include a valid IEEE
   assigned OUI as the first three bytes = of the value field of the TLV. 
   For more information about OUIs see = [3].
   


 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002 
 
   On receipt of an LSP a router MAY = ignore TLVs of type XXX that
   include an OUI from a different = organization, however the router
   MUST flood the LSP onwards as per [1]. =
 
   After the first three bytes of the = value field subsequent bytes may
   be used freely for any purpose provided = that the resultant TLV is
   conformant with [1].
   
   Many organizations will have access to = only one or a few OUIs. 
   Implementers are free to format the = value field after their OUI into
   sub-TLVs so that it may be used for = multiple purposes, and would be
   well advised to do this from the = outset.  Note that if sub-TLVs are
   to be used then the very first = implementation to exist will need to
   recognize the sub-TLV structure, and = ignore sub-TLVs that it does
   not understand whilst searching for = sub-TLVs that it does
   understand.
   
5. Security Considerations
 
   The proprietary TLV raises no new = security issues for IS-IS. 
   Information placed in an IS-IS TLV = cannot be considered secure, and
   so if security is required then an = implementation will need to
   encrypt the information using a = suitable method.
   
6. References
   
   [1] ISO, "Intermediate system to = Intermediate system routeing
   information exchange protocol for use = in conjunction with the
   Protocol for providing the = Connectionless-mode Network Service (ISO
   8473)", ISO/IEC 10589:1992. =
   
   [2] = draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV
   Codepoints in ISIS, Tony Przygienda, = November 2001
   
   [3] http://standards.ieee.org/regauth/oui/index.html =
   
7. Acknowledgments
   
   The author takes no credit for this = work as the concept was
   discussed in the IS-IS Working Group = before the author even became
   an active participant.  = Suggestions for acknowledgement gladly
   received.
   
8. Author's Addresses
   
   Philip Christian
   Nortel Networks Harlow Laboratories =
   London Road, Harlow,
   Essex, CM17 9NA UK
   
   Email: = christi@nortelnetworks.com

------_=_NextPart_001_01C2120C.FEB807FA-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jun 13 16:08:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28742 for ; Thu, 13 Jun 2002 16:08:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5DJirt82215; Thu, 13 Jun 2002 12:44:53 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xmxpita.excite.com (nat5.excitenetwork.com [63.236.75.7]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5DJVit82152 for ; Thu, 13 Jun 2002 12:31:44 -0700 (PDT) (envelope-from dgoodspe@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id 6DFE43E0A; Thu, 13 Jun 2002 15:50:21 -0400 (EDT) To: jparker@axiowave.com, isis-wg@spider.juniper.net Subject: RE: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Received: from [63.104.212.252] by xprdmailfe8.nwk.excite.com via HTTP; Thu, 13 Jun 2002 15:50:21 EST Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20020613195021.6DFE43E0A@xmxpita.excite.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 15:50:21 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff, Just had a chance to pore over the draft and I've got a few comments (hope my word wrapping comes out OK): 1. Because of the different authors, the footnote references are inconsistent. Some sections use just the reference "In [1]", while others use "in ISO [1]", while other make no reference to the footnote "in ISO 10589", some are just "in ISO", while in some, there is no reference when there should be "such-and-such is defined as a constant." (should be ...as a constant in [1]). Other place say "The protocol". I can either cc the WG with the list or send it directly to you. 2. In section 6.1 MaxAge, in the first line "which is set to the MaxAge of the generating IS", should this be: "which is initially set to the MaxAge value on the generating IS" ? 3. Also in section 6.1, the second sentence reads: "When an LSP has been in the network for RemainingLifeTime, it is removed ..." Should this be: "... in the network for RemainingLifeTime without being regenerated ..." ? 4. In section 7.1 ID Length, the last sentence needs a space between notification and isisIDLenMismatch. 5. In section 8.3 Alternative Metrics, there should be blank line after the quote from the ISO doc. 6. In section 14 The Attached Bit, in the 2nd sentence: "Some implementations allow the attachedFlag to be set on (ISs) routing IP traffic under restricted conditions, such as ..." did we mean to say "only be set ... under restricted conditions" or "can additionally be set" ? Thanks, Don --- On Tue 05/21, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: isis-wg@spider.juniper.net Date: Tue 05/21 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt > A small, but very active, subgroup of the WG has been > working on this document for the last month. We considered > a larger set of issues, and decided not to pursue some. > A brief description of those issues is included in the > attached document, remaining.dos. > > Suggestions and edits always welcome: we are still > actively revising the last section, on checking the > Source ID on point-to-point IIH packets. > > - jeff parker > > > 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 : Recommendations for Interoperable IP > > Networks using > > IS-IS > > Author(s) : J. Parker > > Filename : draft-ietf-isis-interoperable-00.txt > > Pages : 19 > > Date : 20-May-02 > > > > 'The difference between theory and practice is greater in > > practice than it is in theory.' (Author unknown) > > This document discusses a number of differences between the IS-IS > > protocol as described in ISO 10589 [1] and RFC 1195 [3] and the > > protocol as it is deployed today. These differences are discussed > as > > a service to those implementing, testing, and deploying the IS-IS > > Protocol to route IP traffic. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt > > > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 15 09:51:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07986 for ; Sat, 15 Jun 2002 09:51:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5FDQBt96702; Sat, 15 Jun 2002 06:26:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bart.cwnt.com (mail.cwnt.com [192.116.246.129]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AD5tt59330 for ; Mon, 10 Jun 2002 06:05:56 -0700 (PDT) (envelope-from amir@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: Thread-Topic: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Thread-Index: AcILM58e39PsBEvfRdGI+f1pV443sAEwkUMgACL/SVA= From: "Amir Hermelin" To: "ISIS-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g5AD5wt59331 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 16:24:12 +0300 Content-Transfer-Encoding: 8bit Alex, once again, comments inline. I've cut out the parts that were in full agreement. Thanks for the comments. Amir. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, June 03, 2002 10:18 PM > To: Amir Hermelin > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] last call on draft > draft-ietf-isis-ext-lsp-frags-00 ... > > > Amir, > > >> > >> Couldn't find any info on how to put S' and S'' in the TLV. > >> > > > Actually, what you need to put here is S (or the is-alias-id, which > > could be different). The S' and S'' (and also S) appear in > the LSP header. > > I think I was confused by the illustration. Could you please > specify more > explicitly which ID is put in the TLV. > Right, I see where the stuff in parenthesis can confuse - removed that and added more explanation in the TLV section. > >> Couldn't find description of any sub-TLVs that would be > >> used to do the above. > > > It's just put there for future or proprietary use - doesn't take up > > any space, I think we should keep it. > > No objection to this, but you need to describe sub-TLV handling > properly. ok. > > >> > >> Couldn't find any rules about sub-TLV handling, i.e., padding > >> and length calculation with it. > >> > >> The format description above should use the illustration > >> style from 1195. > > > I don't fully understand what's missing, but I will add an example. > > I've used the format from the TE-extensions draft, which I > think to be > > clear and well-discussed. Please clarify what you'd like to > see here. > > I'd like the TLV format illustration to be consistent with > 1195, i.e., something like this: > > > x CODE - 24 > > x LENGTH - total length of the value field. > > x VALUE - the following data: > No. of Octets > +--------------------------------+ > | ALIAS SYSTEM ID | 7 > +--------------------------------+ > | SUB-TLV LENGTH | 1 > +--------------------------------+ > | | > . SUB-TLVs . > | | > +--------------------------------+ > agreed. > > >> What about the OL bit? > > > The 3.1.* sections are exceptions. The OL bit should be > set/unset in original and extended LSPs the same as before. > > Don't we want to have consistent values in the "normal" and "extended" > LSPs, at least for mode 2? > > >> > 3.2 Operation Mode 1 Additions > >> ... > >> > When an extended LSP belonging to extended system-id > S' is first > >> > created, the original LSP MUST specify S' as a neighbor, > >> with metric > >> > set to zero. This in order to satisfy the two-way > >> connectivity check > >> > on other routers, as well as to consider the cost of > reaching the > >> > >> I thought that the S'->S link would be needed to satisfy > >> the TWC check for the S->S' one, not the other way around... > >> > > > Depends on which node (S or S') was first considered in > SPF. In Mode 1, it's true > > that always S will be reached first, but this isn't > guaranteed in mode 2. > > Note the name of the section where this text belongs ;) it took me some time, but I finally got your point. Will move the sentence to describe the right direction. > >> We don't have to go through mode-1 to get to mode-2. An upgrade of > >> SW does not necessarily mean changing the LSP origination process. > >> In fact, I would argue that the default setting MUST be > the standard > >> one, i.e., neither mode 1 nor mode 2, and it would be really great > >> if this was spelled out. > >> > > > Your upgrade option is identical to what the draft suggests > - since "standard one" > > is really Mode 1 (you can either have mode-1 or mode-2). > The difference between mode-1 > > and the "standard" way, is that the standard way asserts > when the maximum fragments > > are reached ;-) There's also the additional tlv, but > there's no harm in advertising it. > > > I don't agree here. I think the most common case will be where the > network works and routers' SW gets upgraded. Once upgraded the LSP > origination behavior should not change, i.e., neither mode-1 nor > mode-2 should be activated until explicitly configured by the admin. > This should save from problems with implementations that for some > buggy reason react incorrectly to 0-cost links in non-pseudo LSPs, > or with implementations that implement your spec incorrectly, > as well as this is just a good general practice to not enable new > behavior by default, especially in routing protocols. > Ok, I can add the text to that. However, it's just a recommendation, since implementations can do whatever they want here - the default values are implementation specific. You're right in that I was referring more to the case where the network doesn't work well when the upgrade is done. > > Thanks. > > Alex > > > Thanks. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 15 11:18:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09495 for ; Sat, 15 Jun 2002 11:18:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5FEtCt97145; Sat, 15 Jun 2002 07:55:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ADNbt59445 for ; Mon, 10 Jun 2002 06:23:37 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id GAB17419; Mon, 10 Jun 2002 06:41:44 -0700 (PDT) From: Mike Truskowski Message-Id: <200206101341.GAB17419@wells.cisco.com> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? To: mshand@cisco.com Cc: christi@nortelnetworks.com, isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020610140439.02656f28@jaws.cisco.com> from mike shand at Jun "10," 2002 "02:05:20" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 06:41:44 -0700 (PDT) Content-Transfer-Encoding: 7bit Why not just do the following? +-------------------------------------------------+ | Type | Length | Value | +-------------------------------------------------+ | TLV # | Length | vendor code | "value" | +-------------------------------------------------+ Where the vendor code is a fixed 3-4 octets? I guess one could do this on their own... couldn't they? The major problem I see here is what Philip said he wanted to fix... If vendors are doing this already and this is trying to avoid interoperability problems... then it would seem reasonable that the carrier would go back and install new images or force the vendor to fix the embedded base.. but they won't do either.. thus leaving the problem to stumble over some day... Mike > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > >I suppose that we could define different sub-TLVs, a sub-TLV if the > >identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc > > > >Then folks could use whichever mechanism they prefer, as long as it is a > >globally unique identifier. > > > >Or is that too complex? > > Yes! That's how NSAP addresses got to be so awful :-) > > Mike > > > > >Philip > > > > > -----Original Message----- > > > From: mike shand [mailto:mshand@cisco.com] > > > Sent: Monday, June 10, 2002 12:24 PM > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > Cc: isis-wg@spider.juniper.net > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > that there is > > > >not really any mechanism for private or proprietary use of a TLV. > > > > > > > >Thus various companies (including my own) have just pcked > > > one and used it > > > >for their own purpose. Eventually this will create an > > > interop problem, > > > >but what else is a company to do? > > > > > > > >Is there a way that we could define that a certain TLV number is for > > > >private / proprietary / experimental purposes? > > > > > > > >This would then stop people just picking one. > > > > > > > >I am thinking that there would have to be some sort of > > > entity identifier > > > >in there so that when you see this TLV you know whether it > > > is yours or not. > > > > > > > >Maybe we could define that the first four bytes are an IP > > > address for > > > >example. Any entity large enough to want to use a > > > proprietary TLV would > > > >have a public IP address to put in there, I would have > > > thought. After the > > > >first for bytes then the rest would be free. > > > > > > > >Or maybe there is a better way to identify a particular > > > company / entity > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > >What do people think? > > > > > > > >Philip > > > > > > > > > > This has been suggested before, but never came to anything. I > > > think if it > > > WERE to be done then using something link the MAC OUI would > > > probably work. > > > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > > > > > Mike > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 16 03:32:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29594 for ; Sun, 16 Jun 2002 03:32:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5G77wt01662; Sun, 16 Jun 2002 00:07:58 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AESdt59773 for ; Mon, 10 Jun 2002 07:28:40 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'mike shand'" , Philip Christian Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 10:46:19 -0400 > >Then folks could use whichever mechanism they prefer, as > >long as it is a globally unique identifier. > > > >Or is that too complex? Per Mike's suggestion, an OUI is globally unique and very short. What's not to like? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 16 08:23:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01721 for ; Sun, 16 Jun 2002 08:23:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5GC0Wt03480; Sun, 16 Jun 2002 05:00:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AF0et59933 for ; Mon, 10 Jun 2002 08:00:40 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AFJFWn028801; Mon, 10 Jun 2002 11:19:16 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-308.cisco.com [10.82.241.52]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABQ32146; Mon, 10 Jun 2002 11:18:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20020610111305.01a34f30@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Jeff Learman Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? Cc: "'Mike Truskowski'" , mshand@cisco.com, isis-wg@spider.juniper.net In-Reply-To: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10142854==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 11:14:03 -0400 --=====================_10142854==_.ALT Content-Type: text/plain; charset="us-ascii" IP address assignments are not permanent like OUI assignments are. I realize the chance for collision is very low, though ;-) At 10:06 AM 6/10/2002, Philip Christian wrote: >A vendor code of 4 octets could be an IPv4 address. >Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has. > >Even the smallest vendor can buy a /32 IP address for this purpose. > >That would work. > >Philip > >> -----Original Message----- >> From: Mike Truskowski [mailto:truskows@cisco.com] >> Sent: Monday, June 10, 2002 2:42 PM >> To: mshand@cisco.com >> Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net >> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? >> >> >> Why not just do the following? >> >> +-------------------------------------------------+ >> | Type | Length | Value | >> +-------------------------------------------------+ >> | TLV # | Length | vendor code | "value" | >> +-------------------------------------------------+ >> >> Where the vendor code is a fixed 3-4 octets? >> >> I guess one could do this on their own... couldn't they? >> >> The major problem I see here is what Philip said he wanted to fix... >> >> If vendors are doing this already and this is trying to avoid >> interoperability >> problems... then it would seem reasonable that the carrier >> would go back and >> install new images or force the vendor to fix the embedded >> base.. but they >> won't do either.. thus leaving the problem to stumble over some day... >> >> Mike >> >> > At 13:43 10/06/2002 +0100, Philip Christian wrote: >> > >> > >I suppose that we could define different sub-TLVs, a >> sub-TLV if the >> > >identifier is an IPv4 address, a different sub-TLV if it >> is a MAC address, etc >> > > >> > >Then folks could use whichever mechanism they prefer, as >> long as it is a >> > >globally unique identifier. >> > > >> > >Or is that too complex? >> > >> > Yes! That's how NSAP addresses got to be so awful :-) >> > >> > Mike >> > >> > >> > >> > >Philip >> > > >> > > > -----Original Message----- >> > > > From: mike shand >> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com] >> > > > Sent: Monday, June 10, 2002 12:24 PM >> > > > To: Christian, Philip [HAL02:GI50:EXCH] >> > > > Cc: isis-wg@spider.juniper.net >> > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? >> > > > >> > > > >> > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: >> > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice >> > > > that there is >> > > > >not really any mechanism for private or proprietary >> use of a TLV. >> > > > > >> > > > >Thus various companies (including my own) have just pcked >> > > > one and used it >> > > > >for their own purpose. Eventually this will create an >> > > > interop problem, >> > > > >but what else is a company to do? >> > > > > >> > > > >Is there a way that we could define that a certain TLV >> number is for >> > > > >private / proprietary / experimental purposes? >> > > > > >> > > > >This would then stop people just picking one. >> > > > > >> > > > >I am thinking that there would have to be some sort of >> > > > entity identifier >> > > > >in there so that when you see this TLV you know whether it >> > > > is yours or not. >> > > > > >> > > > >Maybe we could define that the first four bytes are an IP >> > > > address for >> > > > >example. Any entity large enough to want to use a >> > > > proprietary TLV would >> > > > >have a public IP address to put in there, I would have >> > > > thought. After the >> > > > >first for bytes then the rest would be free. >> > > > > >> > > > >Or maybe there is a better way to identify a particular >> > > > company / entity >> > > > >(like a MAC address)? Maybe ISO 8348? >> > > > > >> > > > >What do people think? >> > > > > >> > > > >Philip >> > > > > >> > > > >> > > > This has been suggested before, but never came to anything. I >> > > > think if it >> > > > WERE to be done then using something link the MAC OUI would >> > > > probably work. >> > > > What do you mean by ISO 8348? Do you mean ISO 6523? I >> hope not :-) >> > > > >> > > > Mike >> > > > >> > >> > _______________________________________________ >> > Isis-wg mailing list - Isis-wg@spider.juniper.net >> > http://spider.juniper.net/mailman/listinfo/isis-wg >> > >> >> --=====================_10142854==_.ALT Content-Type: text/html; charset="us-ascii"
IP address assignments are not permanent like OUI assignments are.
I realize the chance for collision is very low, though ;-)

At 10:06 AM 6/10/2002, Philip Christian wrote:

A vendor code of 4 octets could be an IPv4 address.
Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has.

Even the smallest vendor can buy a /32 IP address for this purpose.

That would work.

Philip

> -----Original Message-----
> From: Mike Truskowski [mailto:truskows@cisco.com]
> Sent: Monday, June 10, 2002 2:42 PM
> To: mshand@cisco.com
> Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
>
>
> Why not just do the following?
>
> +-------------------------------------------------+
> | Type   |  Length  |       Value                 |
> +-------------------------------------------------+
> | TLV #  |  Length  |  vendor code  |   "value"   |
> +-------------------------------------------------+
>
> Where the vendor code is a fixed 3-4 octets?
>
> I guess one could do this on their own... couldn't they?
>
> The major problem I see here is what Philip said he wanted to fix...
>
> If vendors are doing this already and this is trying to avoid
> interoperability
> problems... then it would seem reasonable that the carrier
> would go back and
> install new images or force the vendor to fix the embedded
> base..  but they
> won't do either.. thus leaving the problem to stumble over some day...
>
> Mike
>
> > At 13:43 10/06/2002 +0100, Philip Christian wrote:
> >
> > >I suppose that we could define different sub-TLVs, a
> sub-TLV if the
> > >identifier is an IPv4 address, a different sub-TLV if it
> is a MAC address, etc
> > >
> > >Then folks could use whichever mechanism they prefer, as
> long as it is a
> > >globally unique identifier.
> > >
> > >Or is that too complex?
> >
> > Yes! That's how NSAP addresses got to be so awful :-)
> >
> >          Mike
> >
> >
> >
> > >Philip
> > >
> > > > -----Original Message-----
> > > > From: mike shand
> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com]
> > > > Sent: Monday, June 10, 2002 12:24 PM
> > > > To: Christian, Philip [HAL02:GI50:EXCH]
> > > > Cc: isis-wg@spider.juniper.net
> > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> > > >
> > > >
> > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:
> > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> > > > that there is
> > > > >not really any mechanism for private or proprietary
> use of a TLV.
> > > > >
> > > > >Thus various companies (including my own) have just pcked
> > > > one and used it
> > > > >for their own purpose.  Eventually this will create an
> > > > interop problem,
> > > > >but what else is a company to do?
> > > > >
> > > > >Is there a way that we could define that a certain TLV
> number is for
> > > > >private / proprietary / experimental purposes?
> > > > >
> > > > >This would then stop people just picking one.
> > > > >
> > > > >I am thinking that there would have to be some sort of
> > > > entity identifier
> > > > >in there so that when you see this TLV you know whether it
> > > > is yours or not.
> > > > >
> > > > >Maybe we could define that the first four bytes are an IP
> > > > address for
> > > > >example.  Any entity large enough to want to use a
> > > > proprietary TLV would
> > > > >have a public IP address to put in there, I would have
> > > > thought. After the
> > > > >first for bytes then the rest would be free.
> > > > >
> > > > >Or maybe there is a better way to identify a particular
> > > > company / entity
> > > > >(like a MAC address)?  Maybe ISO 8348?
> > > > >
> > > > >What do people think?
> > > > >
> > > > >Philip
> > > > >
> > > >
> > > > This has been suggested before, but never came to anything. I
> > > > think if it
> > > > WERE to be done then using something link the MAC OUI would
> > > > probably work.
> > > > What do you mean by ISO 8348? Do you mean ISO 6523? I
> hope not :-)
> > > >
> > > >          Mike
> > > >
> >
> > _______________________________________________
> > Isis-wg mailing list  -  Isis-wg@spider.juniper.net
> > http://spider.juniper.net/mailman/listinfo/isis-wg
> >
>
>
--=====================_10142854==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 16 09:02:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02144 for ; Sun, 16 Jun 2002 09:02:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5GCe1t03744; Sun, 16 Jun 2002 05:40:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from WS0005.indiatimes.com ([203.199.93.15]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5GCStt03665 for ; Sun, 16 Jun 2002 05:28:56 -0700 (PDT) (envelope-from appallar@indiatimes.com) Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA32123 for ; Sun, 16 Jun 2002 17:45:47 +0530 From: "appallar" Message-Id: <200206161215.RAA32123@WS0005.indiatimes.com> To: Reply-To: "appallar" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919" MIME-Version: 1.0 Subject: [Isis-wg] number of routers in an area Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 16 Jun 2002 17:41:57 +0530 --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919 Content-Type: text/plain; charset=us-ascii Hi all, Are there any guidelines, about number of routers that can exist in an area in ISIS? Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain. Any Help regarding this is appretiated, Thanks in Advance, Suryanarayana Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919 Content-Type: text/html; charset=us-ascii

Hi all,

 Are there any guidelines, about number of routers that can exist in an area in ISIS?

Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain.

Any Help regarding this is appretiated,

 

Thanks in Advance,

Suryanarayana

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 17 09:08:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00326 for ; Mon, 17 Jun 2002 09:08:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HCj0t11037; Mon, 17 Jun 2002 05:45:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HCiut11022 for ; Mon, 17 Jun 2002 05:44:56 -0700 (PDT) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5HD4NYs029610; Mon, 17 Jun 2002 09:04:23 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-504.cisco.com [10.82.241.248]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABS09480; Mon, 17 Jun 2002 09:03:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20020617090213.01aeda58@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "appallar" From: Jeff Learman Subject: Re: [Isis-wg] number of routers in an area Cc: In-Reply-To: <200206161215.RAA32123@WS0005.indiatimes.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_56413508==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 09:03:50 -0400 --=====================_56413508==_.ALT Content-Type: text/plain; charset="us-ascii" The protocol does not impose any standards. This is a weakest-link situation; the router with the least memory or insufficient CPU power will dictate the limitation for that area or level 2 subdomain. Regards, Jeff At 08:11 AM 6/16/2002, appallar wrote: >Hi all, > > Are there any guidelines, about number of routers that can exist in an area in ISIS? > >Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain. > >Any Help regarding this is appretiated, > > > >Thanks in Advance, > >Suryanarayana > > > >---------- >Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com >Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=====================_56413508==_.ALT Content-Type: text/html; charset="us-ascii"
The protocol does not impose any standards.  This is a weakest-link
situation; the router with the least memory or insufficient CPU
power will dictate the limitation for that area or level 2 subdomain.

Regards,
Jeff

At 08:11 AM 6/16/2002, appallar wrote:

Hi all,

 Are there any guidelines, about number of routers that can exist in an area in ISIS?

Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain.

Any Help regarding this is appretiated,

 

Thanks in Advance,

Suryanarayana

 
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=====================_56413508==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 17 14:37:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15594 for ; Mon, 17 Jun 2002 14:37:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIEPt12641; Mon, 17 Jun 2002 11:14:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f100.law7.hotmail.com [216.33.237.100]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HI7Xt12601 for ; Mon, 17 Jun 2002 11:07:33 -0700 (PDT) (envelope-from wongkent@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Jun 2002 11:26:37 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 17 Jun 2002 18:26:37 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jun 2002 18:26:37.0877 (UTC) FILETIME=[8498BE50:01C2162C] Subject: [Isis-wg] testing, please ignore Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 18:26:37 +0000 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 17 15:30:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17664 for ; Mon, 17 Jun 2002 15:30:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HJ78t12938; Mon, 17 Jun 2002 12:07:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIg9t12805 for ; Mon, 17 Jun 2002 11:42:09 -0700 (PDT) (envelope-from prz@redback.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g5HJ1DX17483 for ; Mon, 17 Jun 2002 12:01:13 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 17 Jun 2002 11:59:25 -0700 Received: from redback.com ([63.200.50.126]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXV00IMI6538Q@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Mon, 17 Jun 2002 12:01:13 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net, Alex Zinin , Bill Fenner , David Ward , Tony Li Reply-to: prz@redback.com Message-id: <3D0DFAE6.237BE9EC@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 17 Jun 2002 18:59:25.0281 (UTC) FILETIME=[1942C510:01C21631] Subject: [Isis-wg] ISIS drafts status summary ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 08:06:14 -0700 Content-Transfer-Encoding: 7BIT To keep tab on things and for Tony Ward's benefit status to things we are in. Alex, pls take according drafts that are to publication after last call forward (I will send another message to iesg secretary) 1. draft-ietf-isis-ext-lsp-frags-00 last call ended 5/22/02. I still see comments on the list. From that I deduct last call is going on 2. draft-ietf-isis-3way-06 passed last call as of 5/3/02. Alex took it to IESG. 3. draft draft-ietf-isis-wg-multi-topology-02 has been updated to -03, passed last call as of 3/19/02. Please move forward to publication 4. draft-ietf-isis-traffic-04.txt passed last call as of 02/04/02. Please move forward to publication and since last time 1. draft-ietf-isis-wg-tlv-codepoints-01.txt waiting for publication 2. draft-ietf-isis-ipv6-02.txt waiting for publication 3. draft-ietf-isis-hmac-03.txt waiting for publication 4. draft-ietf-isis-wg-snp-checksum-03.txt waiting for publication unduly yours -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 17 17:18:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20248 for ; Mon, 17 Jun 2002 17:18:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HKtWt13461; Mon, 17 Jun 2002 13:55:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HKQOt13315 for ; Mon, 17 Jun 2002 13:26:24 -0700 (PDT) (envelope-from zinin@psg.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g5HKjTX20331 for ; Mon, 17 Jun 2002 13:45:29 -0700 (PDT) X-JNPR-Received-From: outside Received: from psg.com ([147.28.0.62]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 17 Jun 2002 13:43:40 -0700 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17K3NQ-000I0D-00; Mon, 17 Jun 2002 13:45:28 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18213216476.20020617134404@psg.com> To: Tony Przygienda CC: isis-wg@juniper.net, Alex Zinin , Bill Fenner , David Ward , Tony Li Subject: Re: [Isis-wg] ISIS drafts status summary ... In-Reply-To: <3D0DFAE6.237BE9EC@redback.com> References: <3D0DFAE6.237BE9EC@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2002 20:43:41.0095 (UTC) FILETIME=[AA043B70:01C2163F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 13:44:04 -0700 Content-Transfer-Encoding: 7bit Tony, Some comments on the draft status below, please. > To keep tab on things and for Tony Ward's benefit status to things we are in. Alex, pls take > according drafts that are > to publication after last call forward (I will send another message to iesg secretary) > 1. draft-ietf-isis-ext-lsp-frags-00 last call ended 5/22/02. I still see comments on the list. > From that I deduct last call is going on Amir and I exchanged a couple of messages off the list and I think the discussion converged. Unless there were more comments besides mine, I think we're expecting a new version. > 2. draft-ietf-isis-3way-06 passed last call as of 5/3/02. Alex took it to IESG. Approved by the IESG last Thursday. Should be going to the rfc-ed's queue now. > 3. draft draft-ietf-isis-wg-multi-topology-02 has been updated to -03, passed last call as of > 3/19/02. Please move forward to publication AD-review comments provided to the authors on 05/01/02. Last heard from them on 05/10/02. Expecting new version. > 4. draft-ietf-isis-traffic-04.txt passed last call as of 02/04/02. Please move forward to > publication AD-review comments provided for -04 on 05/01/02. Last heard from tli on 05/02/02. Expecting new version. > and since last time > 1. draft-ietf-isis-wg-tlv-codepoints-01.txt waiting for publication > 2. draft-ietf-isis-ipv6-02.txt waiting for publication AD comments provided; new version needed, waiting for the author. > 3. draft-ietf-isis-hmac-03.txt waiting for publication AD comments provided; new version needed, waiting for the authors. > 4. draft-ietf-isis-wg-snp-checksum-03.txt waiting for publication Alex _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 17 18:45:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22240 for ; Mon, 17 Jun 2002 18:45:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HMLWt13886; Mon, 17 Jun 2002 15:21:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f239.law7.hotmail.com [216.33.237.239]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HM6ht13808 for ; Mon, 17 Jun 2002 15:06:43 -0700 (PDT) (envelope-from wongkent@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Jun 2002 15:25:48 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 17 Jun 2002 22:25:48 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jun 2002 22:25:48.0826 (UTC) FILETIME=[EE6DC7A0:01C2164D] Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 22:25:48 +0000 Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. Thanks. Kent Wong _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jun 21 09:57:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13079 for ; Fri, 21 Jun 2002 09:57:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5LDW5t39087; Fri, 21 Jun 2002 06:32:05 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5LDFJt39005 for ; Fri, 21 Jun 2002 06:15:19 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] FW: ISIS MIB update Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 09:34:36 -0400 > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Thursday, June 20, 2002 8:14 PM > Subject: RE: ISIS MIB update > > Table 10 which defined the alternative multicast addresses > for 802.5 was deleted as per TC1 (published in 1992). The > defect report which I have (hardcopy only unfortunately - > be happy to FAX to anybody who really wants it) discusses > the issue at some length, but concludes by saying that > various groups have reviewed the issues and agreed that > > "token ring ISs be required to use the proper multicast addresses" > > It then specified deletion of the related material from ISO 10589. > > Those who were involved at the time may remember more... > > Les Thanks, Les. I'll remove the associated knob from the MIB. One less thing to puzzle future generations. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 16:13:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03234 for ; Sat, 22 Jun 2002 16:13:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MJjBt49848; Sat, 22 Jun 2002 12:45:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 17:50:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04478 for ; Sat, 22 Jun 2002 17:49:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MLPCt50323; Sat, 22 Jun 2002 14:25:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 18:09:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04844 for ; Sat, 22 Jun 2002 18:09:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MLiCt50444; Sat, 22 Jun 2002 14:44:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 18:27:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05091 for ; Sat, 22 Jun 2002 18:27:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MM2Bt50558; Sat, 22 Jun 2002 15:02:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 18:44:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05347 for ; Sat, 22 Jun 2002 18:44:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MMKBt50656; Sat, 22 Jun 2002 15:20:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 19:03:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05654 for ; Sat, 22 Jun 2002 19:03:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MMcCt50768; Sat, 22 Jun 2002 15:38:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R4fkt50727 for ; Sun, 26 May 2002 21:41:46 -0700 (PDT) (envelope-from yjim@lge.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4R4wYn95599 for ; Sun, 26 May 2002 21:58:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail.lge.co.kr ([156.147.1.150]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:57:05 -0700 Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R4saE14387 for ; Mon, 27 May 2002 13:54:37 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052713323685:1685348 ; Mon, 27 May 2002 13:32:36 +0900 Message-ID: <010e01c20537$c7286a50$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Cc: "Yongjun Im" Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 01:32:36 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 02:00:14 PM, Serialize complete at 05/27/2002 02:00:14 PM Content-Type: text/plain; charset="ks_c_5601-1987" X-OriginalArrivalTime: 27 May 2002 04:57:05.0437 (UTC) FILETIME=[F27DD4D0:01C2053A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R4fkt50728 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 13:34:23 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 19:22:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05832 for ; Sat, 22 Jun 2002 19:22:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MMvBt50893; Sat, 22 Jun 2002 15:57:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f128.law7.hotmail.com [216.33.237.128]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIpbt12850 for ; Mon, 17 Jun 2002 11:51:37 -0700 (PDT) (envelope-from wongkent@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Jun 2002 12:10:41 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 17 Jun 2002 19:10:41 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jun 2002 19:10:41.0768 (UTC) FILETIME=[AC7A7E80:01C21632] Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 19:10:41 +0000 Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. Along the same line of thought, there is no need for a separate T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 22 19:40:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06021 for ; Sat, 22 Jun 2002 19:40:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5MNFBt50999; Sat, 22 Jun 2002 16:15:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 20:00:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06744 for ; Sun, 23 Jun 2002 20:00:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5NNY8t58000; Sun, 23 Jun 2002 16:34:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 20:19:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07018 for ; Sun, 23 Jun 2002 20:19:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5NNs8t58100; Sun, 23 Jun 2002 16:54:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 20:35:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07318 for ; Sun, 23 Jun 2002 20:35:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O0A8t58218; Sun, 23 Jun 2002 17:10:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 20:50:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07484 for ; Sun, 23 Jun 2002 20:50:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O0Q9t58324; Sun, 23 Jun 2002 17:26:09 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 21:07:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07712 for ; Sun, 23 Jun 2002 21:07:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O0g8t58420; Sun, 23 Jun 2002 17:42:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 21:23:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07910 for ; Sun, 23 Jun 2002 21:23:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O0x8t58525; Sun, 23 Jun 2002 17:59:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 23 21:40:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08231 for ; Sun, 23 Jun 2002 21:40:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O1F8t58632; Sun, 23 Jun 2002 18:15:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H6n4t77935 for ; Thu, 16 May 2002 23:49:04 -0700 (PDT) (envelope-from Tony.Li@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 09DFD23C36; Fri, 17 May 2002 00:06:07 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4H74hvM018405; Fri, 17 May 2002 00:04:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Message from the ITU Message-ID: Thread-Topic: [Isis-wg] Message from the ITU Thread-Index: AcH9QzVOViOjhqXJSR6e8y56iuPGswALcUXA From: "Tony Li" To: "Les Ginsberg" , "RJ Atkinson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4H6n4t77936 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 00:04:43 -0700 Content-Transfer-Encoding: 8bit An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 24 04:09:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25271 for ; Mon, 24 Jun 2002 04:09:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O7iBt60510; Mon, 24 Jun 2002 00:44:11 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O7U8t60416 for ; Mon, 24 Jun 2002 00:30:08 -0700 (PDT) (envelope-from prz@redback.com) X-JNPR-Received-From: outside Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.12.3/8.12.3) with ESMTP id g5O7noRj085261 for ; Mon, 24 Jun 2002 00:49:53 -0700 (PDT) Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 24 Jun 2002 00:45:37 -0700 Received: from redback.com ([63.200.50.6]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GY7003MB9N6X4@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Mon, 24 Jun 2002 00:47:30 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3D16979F.9A143203@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 24 Jun 2002 07:45:37.0156 (UTC) FILETIME=[211CB440:01C21B53] X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Subject: [Isis-wg] summer cleaning done ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 23 Jun 2002 20:53:03 -0700 Content-Transfer-Encoding: 7BIT Manoj was kind enough to nuke all the spam that was clogging mailman and restart it to alleviate complaints we had about excessive delays on the list. We'll observe it over next couple of days ... Again, without subscription, there is little chance your mail will make it here or even be looked at. Spammer script kiddies are just too powerfull thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 24 10:08:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07718 for ; Mon, 24 Jun 2002 10:08:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ODh7t62631; Mon, 24 Jun 2002 06:43:07 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5ODKMt62523 for ; Mon, 24 Jun 2002 06:20:22 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id GAA16171; Mon, 24 Jun 2002 06:40:01 -0700 (PDT) From: Mike Truskowski Message-Id: <200206241340.GAA16171@wells.cisco.com> Subject: Re: [Isis-wg] Message from the ITU To: Tony.Li@procket.com Cc: ginsberg@pluris.com, rja@extremenetworks.com, jonathan.sadler@tellabs.com, isis-wg@spider.juniper.net In-Reply-To: from Tony Li at May "17," 2002 "00:04:43" am X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 06:40:01 -0700 (PDT) Content-Transfer-Encoding: 7bit Unfortunately, this is a great opportunity to see the problems we face in having different standards bodies which must work together or face responding to each others variations of the original document.. And I know the other side... like: 1. Let the market decide 2. There's only a few major suppliers of IP so they'll build what they want... the list of comments goes on... Recently, the one SG in the ITU indicated a need to re-architect MPLS. When will they see a need to re-architect IP? It is my opinion that this group is now taking authority of ISIS. Therefore it is important that whatever you do with the document and whichever body it is forwarded to .. it must be on a standards track so as to be referencable in other standard bodies. If you want to display it as a Standards track RFC while it is being accepted in ISO. Then do it. I support this. Mike > > > > An out of the box alternative is for the IS-IS WG to simply be > 'rude' and put its documents on the standards track. > > Any objections? > > Tony > > > > | -----Original Message----- > | From: Les Ginsberg [mailto:ginsberg@pluris.com] > | Sent: Thursday, May 16, 2002 6:35 PM > | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com > | Cc: isis-wg@spider.juniper.net > | Subject: RE: [Isis-wg] Message from the ITU > | > | > | Having worked on the ISO 10589:2001 draft within ISO, I > | would be very > | surprised to learn that ANSI thinks it owns the IS-IS > | spec. As far as I > | know it is owned by JTC1/SC6/WG7. > | > | More importantly, your mail states that the reason IS-IS WG > | drafts are on > | the Informational track is because the IETF does not own the IS-IS > | specification and therefore does not feel it in its purview > | to define > | extensions to the protocol which are "standards". If true, > | this would > | suggest that it is necessary that either: > | > | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO > | documents > | b)IETF be empowered to issue IS-IS extensions which are standards > | c)IETF take ownership of the IS-IS standard > | > | Having spoken to both IETF and ISO leadership on this > | issue, I have no > | reason to think that any solution to this impasse > | acceptable to both sides > | has been offered. > | > | Given that we have even more compelling reasons now to want > | to fix this, I > | would hope that leadership on "all sides of the aisle" > | would find a way to > | make Ran's fantasy come true. > | > | Les > | > | > | > > | > > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > | > > This is why I wish that the IS-IS working group could have > | > its drafts > | > > achive Standards track. Then they would be available > | as normative > | > > references to other bodies, such as the ITU. > | > > > | > > Unfortunately, as I understand it, the IETF is > | sensative to JTC1's > | > > "ownership" of IS-IS and therefore the RFCs are limited to > | > Informational > | > > status at best. > | > > | > IETF has asked (formally) ANSI, who apparently really are the > | > standards > | > body for IS-IS under ISO (ANSI rather than JTC1) about > | handing over > | > change control > | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) > | reports that I > | > hear are > | > that ANSI either didn't respond or said "no we don't want > | to do that". > | > > | > IETF is not publishing IS-IS stuff as standards-track because > | > change-control hasn't been handed over to IETF from ANSI. > | > > | > Consequently, I find this whole thread a bit confusing. > | > Perhaps others > | > also do. > | > > | > A fantasy that occurs to me right now would be to get the > | IETF IS-IS > | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > | > the applicable ITU-T folks all in the same room -- with a goal of > | > trying to find some more productive process and path forwards > | > for all of us. > | > > | > Ran > | > rja@extremenetworks.com > | > > | > _______________________________________________ > | > Isis-wg mailing list - Isis-wg@spider.juniper.net > | > http://spider.juniper.net/mailman/listinfo/isis-wg > | > > | _______________________________________________ > | Isis-wg mailing list - Isis-wg@spider.juniper.net > | http://spider.juniper.net/mailman/listinfo/isis-wg > | _______________________________________________ > | Isis-wg-external mailing list > | Isis-wg-external@mailist.procket.com > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > | > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jun 24 11:59:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13913 for ; Mon, 24 Jun 2002 11:59:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5OFYWt63190; Mon, 24 Jun 2002 08:34:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5OF53t63052 for ; Mon, 24 Jun 2002 08:05:03 -0700 (PDT) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (sjck-dial-gw5-11.cisco.com [10.19.238.12]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA23669; Mon, 24 Jun 2002 16:24:22 +0100 (BST) Message-Id: <4.3.2.7.2.20020624082423.0a969f08@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mike Truskowski From: John Harper Subject: Re: [Isis-wg] Message from the ITU Cc: Tony.Li@procket.com, ginsberg@pluris.com, rja@extremenetworks.com, jonathan.sadler@tellabs.com, isis-wg@spider.juniper.net In-Reply-To: <200206241340.GAA16171@wells.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 08:24:34 -0700 FWIW I agree 100% with Tony L. John At 06:40 24/06/2002 -0700, Mike Truskowski wrote: >Unfortunately, this is a great opportunity to see the problems we >face in having different standards bodies which must work together >or face responding to each others variations of the original >document.. > >And I know the other side... like: >1. Let the market decide >2. There's only a few major suppliers of IP so they'll build what >they want... >the list of comments goes on... > >Recently, the one SG in the ITU indicated a need to re-architect >MPLS. When will they see a need to re-architect IP? > >It is my opinion that this group is now taking authority of ISIS. >Therefore it is important that whatever you do with the document >and whichever body it is forwarded to .. it must be on a standards >track so as to be referencable in other standard bodies. > >If you want to display it as a Standards track RFC while it is being >accepted in ISO. Then do it. I support this. > >Mike > > > > > > > > > > An out of the box alternative is for the IS-IS WG to simply be > > 'rude' and put its documents on the standards track. > > > > Any objections? > > > > Tony > > > > > > > > | -----Original Message----- > > | From: Les Ginsberg [mailto:ginsberg@pluris.com] > > | Sent: Thursday, May 16, 2002 6:35 PM > > | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com > > | Cc: isis-wg@spider.juniper.net > > | Subject: RE: [Isis-wg] Message from the ITU > > | > > | > > | Having worked on the ISO 10589:2001 draft within ISO, I > > | would be very > > | surprised to learn that ANSI thinks it owns the IS-IS > > | spec. As far as I > > | know it is owned by JTC1/SC6/WG7. > > | > > | More importantly, your mail states that the reason IS-IS WG > > | drafts are on > > | the Informational track is because the IETF does not own the IS-IS > > | specification and therefore does not feel it in its purview > > | to define > > | extensions to the protocol which are "standards". If true, > > | this would > > | suggest that it is necessary that either: > > | > > | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO > > | documents > > | b)IETF be empowered to issue IS-IS extensions which are standards > > | c)IETF take ownership of the IS-IS standard > > | > > | Having spoken to both IETF and ISO leadership on this > > | issue, I have no > > | reason to think that any solution to this impasse > > | acceptable to both sides > > | has been offered. > > | > > | Given that we have even more compelling reasons now to want > > | to fix this, I > > | would hope that leadership on "all sides of the aisle" > > | would find a way to > > | make Ran's fantasy come true. > > | > > | Les > > | > > | > > | > > > | > > > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > > | > > This is why I wish that the IS-IS working group could have > > | > its drafts > > | > > achive Standards track. Then they would be available > > | as normative > > | > > references to other bodies, such as the ITU. > > | > > > > | > > Unfortunately, as I understand it, the IETF is > > | sensative to JTC1's > > | > > "ownership" of IS-IS and therefore the RFCs are limited to > > | > Informational > > | > > status at best. > > | > > > | > IETF has asked (formally) ANSI, who apparently really are the > > | > standards > > | > body for IS-IS under ISO (ANSI rather than JTC1) about > > | handing over > > | > change control > > | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) > > | reports that I > > | > hear are > > | > that ANSI either didn't respond or said "no we don't want > > | to do that". > > | > > > | > IETF is not publishing IS-IS stuff as standards-track because > > | > change-control hasn't been handed over to IETF from ANSI. > > | > > > | > Consequently, I find this whole thread a bit confusing. > > | > Perhaps others > > | > also do. > > | > > > | > A fantasy that occurs to me right now would be to get the > > | IETF IS-IS > > | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > > | > the applicable ITU-T folks all in the same room -- with a goal of > > | > trying to find some more productive process and path forwards > > | > for all of us. > > | > > > | > Ran > > | > rja@extremenetworks.com > > | > > > | > _______________________________________________ > > | > Isis-wg mailing list - Isis-wg@spider.juniper.net > > | > http://spider.juniper.net/mailman/listinfo/isis-wg > > | > > > | _______________________________________________ > > | Isis-wg mailing list - Isis-wg@spider.juniper.net > > | http://spider.juniper.net/mailman/listinfo/isis-wg > > | _______________________________________________ > > | Isis-wg-external mailing list > > | Isis-wg-external@mailist.procket.com > > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > > | > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jun 26 16:37:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09913 for ; Wed, 26 Jun 2002 16:37:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5QKC4t78242; Wed, 26 Jun 2002 13:12:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f247.law7.hotmail.com [216.33.237.247]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5QJpUt78146 for ; Wed, 26 Jun 2002 12:51:30 -0700 (PDT) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Jun 2002 13:11:32 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 26 Jun 2002 20:11:31 GMT X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jun 2002 20:11:32.0016 (UTC) FILETIME=[A9E9E300:01C21D4D] Subject: [Isis-wg] 3 Way Handshake Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 20:11:31 +0000 I have a question regarding the 3 way handshake draft (I guess now it is in limbo land where it is waiting to become an informational RFC). The state machine indicates that if the existing 3 way adjacency state is UP and we receive a 3 way adjacency state of DOWN, the action should be INIT. This does not seem right. The fact that you had a 3 way state that was up and now the nbr says it is down, shouldnt we restart the adjacency? This may be one way of the nbr wanting to restart the adjacency. I think the state should be DOWN and not INIT. Same thing applies in the case where you receive a ptop IIH with the 3 way state TLV being absent. The draft says "A received ptop IIH PDU may or may not contain the PTOP 3 way adj option. If it does not, the link is assumed to be functional in both directions....". If you already had a 3 way nbr state of UP and let's say the IS got switched with another IS that does not support 3 way TLV, going by the draft, we will not detect the change in the system. We will continue to keep the adjacency when in fact we should restart it. Comments? Suresh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jun 28 14:13:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11381 for ; Fri, 28 Jun 2002 14:13:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5SHl1t91353; Fri, 28 Jun 2002 10:47:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5SHgCt91325 for ; Fri, 28 Jun 2002 10:42:12 -0700 (PDT) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.4/8.12.4) with ESMTP id g5SI2O89009643 for ; Fri, 28 Jun 2002 08:02:25 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 08:09:02 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540502DD6B64@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: isis-wg@spider.juniper.net Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] Inclusion of zero Length VLF Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 28 Jun 2002 08:08:55 -1000 Hi, I just observed from one of the routers in our lab include VLF which has zero length in its PDU. For example, in the IIH, it contains an IS Neighbor VLF with no MAC address in it. It looks to me that it won't do any harm, it will be ignored anyway by the receiving router; But it is meaningless to include something like that also. Is this one of the common ways of encoding a PDU? Thanks, C. Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 29 18:48:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07158 for ; Sat, 29 Jun 2002 18:48:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5TMLst20540; Sat, 29 Jun 2002 15:21:54 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5O85Lt60621 for ; Mon, 24 Jun 2002 01:05:21 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp90.cisco.com [10.50.0.89]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA10853; Mon, 24 Jun 2002 09:25:04 +0100 (BST) Message-Id: <4.3.2.7.2.20020624091932.042cbef0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Kent Wong" From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-01.txt Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 09:25:02 +0100 I think I've answered most of this already, but with the recent problems on the list I'm not sure what has got through. So, here goes again. Mike At 19:10 17/06/2002 +0000, Kent Wong wrote: >Hi, > >I have some questions and comments on the isis restart draft: > >1. On Page 6 >"....a router MAY transmit one or more normal IIHs >(containing a restart option, but with RR and RA clear) after the >initial RR/RA exchange, but before synchronization has been >achieved, in order to extend the holding time of the neighbors >adjacencies, beyond that indicated in the remaining time field of >the neighbors IIH with the RA bit set." > >When a router does this, should it also extend T3 to be the new >holding time? Yes. > Otherwise, even though we extend nbr's holding time >for the adjacency, T3 will still expire in a short time and LSP >with OL bit set will be generated and the graceful restart will >fail anyway. > >2. Instead of sending normal IIH after initial RR/RA exchange, >would it make more sense that if this is a planned restart, >a normal IIH with a large holding time is sent before the router >going down so that nbr will hold the adjacency until restarting >router finishes the complete restart procedure. In that way, there >is no need to send extra normal IIH after initial RR/RA exchange. You could do that. >3. If T2 on both levels expires/cancelled, it means end of >database resync and if T3 is still running, we should cancel >T3 at this time. Is that correct? The draft did not say this explicitly. Yes. >4. Along the same line of thought, there is no need for a separate >T2 and T3. Because when T2 expires/cancels before T3, T3 should be >cancelled anyway. The only case T3 is supposed to be useful is >when T3 expires before T2. The draft states that > >"If the timer T3 expires before all the T2 timers have expired, this >indicates that the synchronization process is taking longer than >minimum holding time of the neighbors. The router's own LSP(s) for >levels which have not yet completed their first SPF computation are >then flooded with the overload bit set to indicate that the router's >LSPDB is not yet synchronized (and other routers should therefore >not compute routes through this router)." > >However this assumes that the restarting router has acquired its >own pre-start LSP before T3 expires. What if T3 expires even before >it acquires its pre-start LSP? In that case, it doesn't know what >sequence number it should use in its zero LSP to set the OL bit. >If the seq num it uses is smaller than the seq num in its nbr's DB, >then the zero LSP will be ignored by nbr anyway. No. It starts with a seq no. of 1, but thisn will cause any neighbors with a higher seq number to send back that higher seq number, then the originator will "trump" it with a yet higher seq number. Normal update process operation. >So why not just combine T2 and T3 into a single timer and set the >timer to be the min. remaining holding time of its nbr. If the timer >expires before it DB re-sync, then graceful restart fails >and everything reverts back to normal. Isn't this much more simpler >and effective? You COULD implement it that way. It makes no difference to the semantics of the timers. >5. On section 4.3.1.1, the draft mentions the behavior of a router >when it starts for the first time. Does it mean this draft intends to >change the normal ISIS behavior even though it is not a restart? Yes. >That means we need to start T2 (but no T1, T3) for each level even >we start for the first time. However, it may not be desirable to set >the OL bit every time ISIS comes up. This should be decided by the >network admin on individual cases whether to set the OL bit or not. Also need T1. >6. Just for clarification, in the draft, it mentions "own" LSP >many times, sometimes it mention own non-pseudonode LSP, sometimes >it mention own LSP including pseudonode. Sometimes, it simply >mention "own" LSP. Should we interpret the "own" LSP as including >pseudonode LSP if it doesn't specify otherwise? Yes, hopefully. >Thanks! > >---Kent Wong > > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jun 29 19:29:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07805 for ; Sat, 29 Jun 2002 19:29:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5TN3st20763; Sat, 29 Jun 2002 16:03:54 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 08:09:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28998 for ; Sun, 30 Jun 2002 08:09:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UBhut24741; Sun, 30 Jun 2002 04:43:56 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 08:27:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29462 for ; Sun, 30 Jun 2002 08:27:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UC3Wt24867; Sun, 30 Jun 2002 05:03:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 08:45:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29710 for ; Sun, 30 Jun 2002 08:45:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UCLXt24982; Sun, 30 Jun 2002 05:21:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 09:02:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29924 for ; Sun, 30 Jun 2002 09:02:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UCcWt25088; Sun, 30 Jun 2002 05:38:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 09:19:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00275 for ; Sun, 30 Jun 2002 09:19:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UCtWt25184; Sun, 30 Jun 2002 05:55:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 09:37:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00601 for ; Sun, 30 Jun 2002 09:37:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UDDWt25296; Sun, 30 Jun 2002 06:13:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 09:54:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00884 for ; Sun, 30 Jun 2002 09:54:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UDUXt25411; Sun, 30 Jun 2002 06:30:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 10:11:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01280 for ; Sun, 30 Jun 2002 10:11:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UDlWt25522; Sun, 30 Jun 2002 06:47:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 10:29:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01645 for ; Sun, 30 Jun 2002 10:29:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UE4Xt25630; Sun, 30 Jun 2002 07:04:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 10:45:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02048 for ; Sun, 30 Jun 2002 10:45:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UELXt25753; Sun, 30 Jun 2002 07:21:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 11:02:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02462 for ; Sun, 30 Jun 2002 11:02:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UEcWt25854; Sun, 30 Jun 2002 07:38:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 11:19:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02894 for ; Sun, 30 Jun 2002 11:19:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UEtWt25967; Sun, 30 Jun 2002 07:55:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 11:37:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03572 for ; Sun, 30 Jun 2002 11:37:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UFCWt26084; Sun, 30 Jun 2002 08:12:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 11:53:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04439 for ; Sun, 30 Jun 2002 11:53:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UFTWt26185; Sun, 30 Jun 2002 08:29:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 12:10:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05139 for ; Sun, 30 Jun 2002 12:10:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UFkXt26306; Sun, 30 Jun 2002 08:46:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 12:27:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05611 for ; Sun, 30 Jun 2002 12:27:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UG3Wt26412; Sun, 30 Jun 2002 09:03:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HIKZt12679 for ; Mon, 17 Jun 2002 11:20:36 -0700 (PDT) (envelope-from slattanze@allegronetworks.com) Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jun 2002 14:39:39 -0400 Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> From: Sharon Lattanze To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Isis-wg] unsubscribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 14:39:39 -0400 Unsubscribe slattanze@allegronetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 13:32:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07331 for ; Sun, 30 Jun 2002 13:32:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UH8ot26822; Sun, 30 Jun 2002 10:08:50 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f62.law7.hotmail.com [216.33.237.62]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5HMSot13924 for ; Mon, 17 Jun 2002 15:28:50 -0700 (PDT) (envelope-from wongkent@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Jun 2002 15:47:56 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 17 Jun 2002 22:47:55 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jun 2002 22:47:56.0164 (UTC) FILETIME=[05957C40:01C21651] Subject: [Isis-wg] draft-ietf-isis-restart-01.txt [continued] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 22:47:55 +0000 Hi, Some more questions and comments: 4. I don't understand why there is a need for two different timers T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jun 30 14:10:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07904 for ; Sun, 30 Jun 2002 14:09:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5UHjXt27040; Sun, 30 Jun 2002 10:45:33 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g5AGaQt60364 for ; Mon, 10 Jun 2002 09:36:27 -0700 (PDT) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.50.97]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXI000WZ1N9T8@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Mon, 10 Jun 2002 09:54:46 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? To: Philip Christian Cc: "'Mike Truskowski'" , mshand@cisco.com, isis-wg@spider.juniper.net Message-id: <3D04D741.5010700@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 References: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nortel.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 09:43:45 -0700 Content-Transfer-Encoding: 7BIT Yes, the proposals have been made before and nohting has been written down. I am for using the official OUI, this would be aligned with Frame Relay, ATM and so on. The /32 may fly but unfortunately IP address space is a volatile thing compared to OUIs. I assume any vendor building sophisticated networking gear with ISIS on it will at a certain point have an OUI, I see little value in having a /32-address-based-cottage-industry-of-ISIS-extensions ... So, this time any takers to write it down ? thanks -- tony Philip Christian wrote: > A vendor code of 4 octets could be an IPv4 address. > Then no-one would have to assign them. The vendor just uses a global > IPv4 address that he has. > > Even the smallest vendor can buy a /32 IP address for this purpose. > > That would work. > > Philip > > > -----Original Message----- > > From: Mike Truskowski [ mailto:truskows@cisco.com ] > > Sent: Monday, June 10, 2002 2:42 PM > > To: mshand@cisco.com > > Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > Why not just do the following? > > > > +-------------------------------------------------+ > > | Type | Length | Value | > > +-------------------------------------------------+ > > | TLV # | Length | vendor code | "value" | > > +-------------------------------------------------+ > > > > Where the vendor code is a fixed 3-4 octets? > > > > I guess one could do this on their own... couldn't they? > > > > The major problem I see here is what Philip said he wanted to fix... > > > > If vendors are doing this already and this is trying to avoid > > interoperability > > problems... then it would seem reasonable that the carrier > > would go back and > > install new images or force the vendor to fix the embedded > > base.. but they > > won't do either.. thus leaving the problem to stumble over some day... > > > > Mike > > > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > > > >I suppose that we could define different sub-TLVs, a > > sub-TLV if the > > > >identifier is an IPv4 address, a different sub-TLV if it > > is a MAC address, etc > > > > > > > >Then folks could use whichever mechanism they prefer, as > > long as it is a > > > >globally unique identifier. > > > > > > > >Or is that too complex? > > > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > > > Mike > > > > > > > > > > > > >Philip > > > > > > > > > -----Original Message----- > > > > > From: mike shand > > [mailto:mshand@cisco.com ] > > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > > Cc: isis-wg@spider.juniper.net > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > > that there is > > > > > >not really any mechanism for private or proprietary > > use of a TLV. > > > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > > one and used it > > > > > >for their own purpose. Eventually this will create an > > > > > interop problem, > > > > > >but what else is a company to do? > > > > > > > > > > > >Is there a way that we could define that a certain TLV > > number is for > > > > > >private / proprietary / experimental purposes? > > > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > > > >I am thinking that there would have to be some sort of > > > > > entity identifier > > > > > >in there so that when you see this TLV you know whether it > > > > > is yours or not. > > > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > > address for > > > > > >example. Any entity large enough to want to use a > > > > > proprietary TLV would > > > > > >have a public IP address to put in there, I would have > > > > > thought. After the > > > > > >first for bytes then the rest would be free. > > > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > > company / entity > > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > > > >What do people think? > > > > > > > > > > > >Philip > > > > > > > > > > > > > > > > This has been suggested before, but never came to anything. I > > > > > think if it > > > > > WERE to be done then using something link the MAC OUI would > > > > > probably work. > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > > hope not :-) > > > > > > > > > > Mike > > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg