From isis-wg-admin@spider.juniper.net Sun Jul 1 04:09:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04834 for ; Sun, 1 Jul 2001 04:09:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52834; Sun, 1 Jul 2001 01:09:13 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52822 for ; Sun, 1 Jul 2001 01:08:56 -0700 (PDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id BAA26606; Sun, 1 Jul 2001 01:12:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <156177829084.20010701011218@nexsi.com> To: David Hudek CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3E2194.9D853DEE@ma.ultranet.com> References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com> <14340299757.20010629110004@nexsi.com> <12355656019.20010629151601@nexsi.com> <3B3E2194.9D853DEE@ma.ultranet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 01:12:18 -0700 Content-Transfer-Encoding: 7bit David, >> Thinking more about this... I guess we can go without CSNs in LSPs, >> as the LSP's own SN should be enough in most cases (except for >> the purge case, which is described in HMAC). So, we need only >> two CSN groups---IIH & SNPs. > Sounds good. Allows implementations to easily reorder > types of messages if desired (e.g., high priority hellos) > ------------------------------------------------------------------- > I had another question, but upon reading my email this morning, > I see that it's already been addressed :-) > (problem with restarting after being up for a while... > after restart you are using small seq num but BadGuy replays > one of your previous high seq num to your peer... so peer stops > listening to you until/unless your seq num increments up to the > old value) > I'm definitely NOT a security expert, but since there > were some drawbacks mentioned for the proposed scheme > (issues with NVRAM, and calendar clock), With the reservation that each system will select it's own source for generation ID, I think the nv memory approach is good. If we assume that the genID is saved in the same place as the device's config or other settings, the case of a failure of this block should be extremely rare and would require attention anyway (the router has no config, no IP addresses, no ISIS started, no nothing, so no worries about authentication)... > I'm wondering what would be the drawbacks of taking a page > from the LSP seq num handling and just putting in a mechanism > for an entity to bump up their seq num state if they discover a > prior incarnation with higher state floating about. > They could discover that if the crypto data in a hello > included not only your crypto state (seqNum, or genId + seqNum) > for the message in question, but also your current view of your > neighbor's state for each category (IIH, SNP). You see, when a router goes down, it is very likely that other routers will destroy the adjacency and the associated neighbor data structure by the time it is back. Hence, when the router is back up, it won't see itself's state in the neighbors' Hellos, and I wouldn't like to introduce changes in other parts of implementations. One could also think about maintaining a single CSN per segment and pushing the transmit CSN up whenever a greater one is received. This also has multiple drawbacks. One is decreased key lifetime (since routers are "racing"). The key lifetime is in inverse proportion to the number of routers on the segment. Another is none of the two addresses the case of all routers being restarted, so one would want to save the genID anyway. > Actually, I just thought of one possible bad scenario, but > it seems sort of far-out?... if a BadGuy had a large > history of your prior messages (you had been up a long time), > then they could incrementally fool your neighbor... replay to > set seq num a bit higher than you, then you recover, then they > replay a different one to set yet a bit higher, then you recover, etc. > You could recover with a relatively large extra jump to reduce this, > I suppose, but then you'll start using up the space faster. > If the space is large enough (genID+seqNum) then this > might not be an issue? The above would be possible if the attacker recorded a session and the genID of the router under attack rolled back to zero. The way this problem is addressed now is by making sure the keys are changed before the CSN is used up. I think this is a practically acceptable assumption, since (as mentioned before) each 32-bit CSN is enough for more than 10 years. Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 1 05:46:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09015 for ; Sun, 1 Jul 2001 05:46:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA53433; Sun, 1 Jul 2001 02:47:13 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA53421 for ; Sun, 1 Jul 2001 02:46:19 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f619few59061 for ; Sun, 1 Jul 2001 02:41:42 -0700 (PDT) X-JNPR-Received-From: outside content-class: urn:content-classes:message Subject: RE: [Isis-wg] draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> Thread-Topic: [Isis-wg] draft-ietf-isis-hmac-03.txt Thread-Index: AcEAZ2lCtvutCikbSYO27mScMaW/ywBqEj1g From: "Omer Sali" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id CAA53422 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 12:42:52 +0300 Content-Transfer-Encoding: 8bit Hi, in section 2.1 it says: "Implementations supporting the extensions described in this document should maintain the cryptographic sequence number counter on a per- interface basis." Is it essential to have a different CSN for each interface ? (Clearly it is better, but is it essential?) Having a different CSN means that if we flood an LSP over 100 interface we have to recalculate MD5 100 times. If we adopt Alex's suggestion for using only LSP's own SN we'll get over this drawback. Omer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 1 11:49:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12324 for ; Sun, 1 Jul 2001 11:49:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA54894; Sun, 1 Jul 2001 08:50:13 -0700 (PDT) Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA54878 for ; Sun, 1 Jul 2001 08:49:19 -0700 (PDT) Received: from ma.ultranet.com (209-122-235-171.s2362.apx2.sbo.ma.dialup.rcn.com [209.122.235.171]) by antiochus-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with ESMTP id LAA31450 for ; Sun, 1 Jul 2001 11:46:21 -0400 (EDT) Message-ID: <3B3F7079.5445EB3B@ma.ultranet.com> From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <15162.15644.474511.856119@redcs1.procket.com> <3B3E4F94.1DA6313B@ma.ultranet.com> <3B3E2680.C308B342@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 01 Jul 2001 11:48:25 -0700 Content-Transfer-Encoding: 7bit steve luong wrote: > No, it does not imply that. That sentence does not change the decision > to pad or not to pad the IIH > in anyway. It tells you the sequence of what to do first. The sequence is you > pad the IIH first (if the IIH is supposed to be padded), then do the MD5 > calculation over the entire PDU. While that is certainly a reasonable approach, it is not what the draft rfc currently specifies. If the wording was something more like "This rfc does not take any position regarding hello padding rules, but if a hello is to be padded it MUST occur prior to the hmac-md5 calculation," then I would agree. (and it lets you remain padding agnostic with regard to p2p hellos, allowing for both implementation styles of a) always padding all p2p hellos [which at least one dominant implementation has done], and b) a strictly 10589 compliant implementation which only pads the first p2p hello) Instead, when it speaks of hellos, it currently says, "The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded to the MTU size, if padding is not disabled." which mandates the hmac-md5 calc (SHALL be calculated) qualified by two conditions, a state condition (padding enabled/disabled) and an event condition (padding has occured/padding has not occured). It explicitly says to compute under one of four possible state/event combinations (3 of which are potentially valid, and 1 of which would be a bug), and stands mute on the other cases. The other cases are left ambiguous and so up to the implementors' discretion. I'm reminded of a recent comment by Tony P when talking about some ambiguity in a different draft rfc :-) >The answer is always 'Obviously you do X' >but if not spelled out in some clear specs what X must be , >multiple implementors arrive to different 'X' solutions and >interesting effects will occur. I would simply suggest that the wording in the draft be tightened up a little to reduce the ambiguity. Thanks, dave h _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 1 15:30:14 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13524 for ; Sun, 1 Jul 2001 15:30:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA55767; Sun, 1 Jul 2001 12:29:13 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA55755 for ; Sun, 1 Jul 2001 12:28:51 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f61JOFw63338 for ; Sun, 1 Jul 2001 12:24:15 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA30691; Sun, 1 Jul 2001 12:31:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <86218586660.20010701123135@nexsi.com> To: "Omer Sali" CC: isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 12:31:35 -0700 Content-Transfer-Encoding: 7bit Omer, To make it clear, let's differentiate btw LSPs and all other ISIS packets. The difference is in the fact that LSPs have domain-wide distribution, while other packets are local to a specific segment. As far as link-local packets are concerned, everything is pretty much clear. We need increasing CSNs for everything a router sends. Maintaining one CSN for all interfaces does not give us any benefit, as we have to calculate HMAC anyway. As for LSPs, we have two options---use link-specific CSNs or rely on the ISIS SNs. The choice between the two is essentially the choice between attack prevention and attack detection. CSNs will provide attack prevention, as the attacker will not be able to replay old LSPs. ISIS SNs will not save us from attacks (because once an LSP has been purged, the domain loses the crypto state for it), i.e., the attacker will be able to replay LSPs, but the real originating router will be able to detect the attack and draw the administrator's attention to it. I guess I will change the draft to say CSN MAY be included in an LSP and if it is, the value should be taken from the outbound interface's CSN whenever an LSP is sent. This is somewhat hacky, because it breaks the main principle of link-state routing---"never mess with someone else's link-state data", but this seems to be the only choice, since we don't have LSPs encapsulated into some "update" packets as in OSPF. Alex. > Hi, > in section 2.1 it says: > "Implementations supporting the extensions described in this document > should maintain the cryptographic sequence number counter on a per- > interface basis." > Is it essential to have a different CSN for each interface ? (Clearly it > is better, but is it essential?) > Having a different CSN means that if we flood an LSP over 100 interface > we have to recalculate MD5 100 times. > If we adopt Alex's suggestion for using only LSP's own SN we'll get over > this drawback. > Omer > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 1 19:48:26 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14880 for ; Sun, 1 Jul 2001 19:48:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA56885; Sun, 1 Jul 2001 16:49:13 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA56873 for ; Sun, 1 Jul 2001 16:48:19 -0700 (PDT) Received: from redd2222.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f61Nhgw65433 for ; Sun, 1 Jul 2001 16:43:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd2222.procket.com (8.11.0/8.9.3) with ESMTP id f61NiVb13152; Sun, 1 Jul 2001 16:44:32 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B3FB5DF.53507879@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Omer Sali , isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 01 Jul 2001 16:44:31 -0700 Content-Transfer-Encoding: 7bit Alex Zinin wrote: > > Omer, > > To make it clear, let's differentiate btw LSPs and all other > ISIS packets. The difference is in the fact that LSPs have > domain-wide distribution, while other packets are local to > a specific segment. > > As far as link-local packets are concerned, everything is > pretty much clear. We need increasing CSNs for everything > a router sends. Maintaining one CSN for all interfaces does > not give us any benefit, as we have to calculate HMAC anyway. > > As for LSPs, we have two options---use link-specific CSNs > or rely on the ISIS SNs. The choice between the two is essentially > the choice between attack prevention and attack detection. > CSNs will provide attack prevention, as the attacker will not > be able to replay old LSPs. ISIS SNs will not save us from I have not follow this thread closely so my comment may be just a misunderstanding. I don't expect there is any synchronization of CSN in the whole network. So it is possible for a interface in the network has much larger CSN for another interface in the same network. As a result, one can caputure the LSP on the interface with larger CSN and replay it on the interface with lower CSN and there is still no attack prevention. Thanks, - Derek > attacks (because once an LSP has been purged, the domain loses > the crypto state for it), i.e., the attacker will be able to > replay LSPs, but the real originating router will be able to detect > the attack and draw the administrator's attention to it. > > I guess I will change the draft to say CSN MAY be included > in an LSP and if it is, the value should be taken from the > outbound interface's CSN whenever an LSP is sent. This is > somewhat hacky, because it breaks the main principle of > link-state routing---"never mess with someone else's link-state > data", but this seems to be the only choice, since we don't have LSPs > encapsulated into some "update" packets as in OSPF. > > Alex. > > > Hi, > > > in section 2.1 it says: > > "Implementations supporting the extensions described in this document > > should maintain the cryptographic sequence number counter on a per- > > interface basis." > > > Is it essential to have a different CSN for each interface ? (Clearly it > > is better, but is it essential?) > > > Having a different CSN means that if we flood an LSP over 100 interface > > we have to recalculate MD5 100 times. > > > If we adopt Alex's suggestion for using only LSP's own SN we'll get over > > this drawback. > > > Omer > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 1 20:47:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15154 for ; Sun, 1 Jul 2001 20:47:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA57172; Sun, 1 Jul 2001 17:48:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA57160 for ; Sun, 1 Jul 2001 17:47:33 -0700 (PDT) Received: from redd2222.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f620gtw66033 for ; Sun, 1 Jul 2001 17:42:56 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd2222.procket.com (8.11.0/8.9.3) with ESMTP id f620iWb13194; Sun, 1 Jul 2001 17:44:32 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B3FC3F0.3AFB80CA@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ran Atkinson CC: isis-wg@juniper.net Subject: Re: [Isis-wg] Derek's proposal for MTU discovery in IS-IS References: <200106262310.f5QNA9U28078@redd3174.procket.com> <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 01 Jul 2001 17:44:32 -0700 Content-Transfer-Encoding: 7bit Sorry for the late reply. Given enough interest, I can send out a draft in a week or so for the MTU TLV for IIH. Going through the thread, it appear to me the problem this new TLV does not solve is the FDDI-Ethernet type bridged network Radia mentioned. IMHO, this network model is broken in nature and hopefully it is not wide-spread enough to render the suggestion useless. For Henk's comment - > In theory there are two more problems that can be detected early > when the IIH is really padded to mtu-size. > 1) bit errors or packet corruption that has a higher probability to > occur with larger packets. Supposedly this is something from the > past when transmissions were over copper, not fibre. I suppose it can be better detected/solved by checksum/authentication. > 2) bugs. interfaces that have their MTU off by 1 (or 4. (I have seen > these bugs in cisco)). If the MTU is off such that both side does not match, it would be fine as adjacency is not found and this problem should be caught in early developement. > or routers running out of huge buffers. > stuff like that. Given that only the first IIH is padded, it is not helpful to detect temporary outage of huge buffer. If the outage is permanent, the system should probably detect it and take some action. I agree with Henk that these two issues is not big deal though. Cheers, - Derek Ran Atkinson wrote: > > Henk's historical analysis is extremely helpful. > I hope we are all now focused on the problem at hand. > Thanks much for the detailed analysis and history. > > At 19:27 26/06/01, Derek Yeung wrote: > > OSPF have the same problem. OSPF solves the problem by putting the > >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable > >to put a TLV in IIH to carry the MTU instead of padding IIH to full > >MTU size ? > > This seems like a simpler approach. The concept is known to > work (thanks to OSPF). Why don't we just try this to solve the > immediate IS-IS issue that Henk outlined ? Oh, and if we do this, > it might not hurt to add a MIB object or two to make MTU mismatches > discovered by IS-IS easy for operators to grab via SNMP. > > Quite separately, I'll probably draft up an "IP over > Jumbogram Ethernet-II Framing" spec that just documents the > as deployed IP/Ethernet practice, as an Informational RFC. I don't > see that as an IS-IS WG work item, in no small part because IS-IS > does not use Ethernet-II Framing. > > Cheers, > > Ran > rja@inet.org > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 01:26:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20392 for ; Mon, 2 Jul 2001 01:26:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA58325; Sun, 1 Jul 2001 22:29:13 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA58313 for ; Sun, 1 Jul 2001 22:28:39 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f625Nxw68786 for ; Sun, 1 Jul 2001 22:23:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id WAA01203; Sun, 1 Jul 2001 22:32:13 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <143254621456.20010701223210@nexsi.com> To: Derek Yeung CC: Omer Sali , isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3FB5DF.53507879@procket.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 22:32:10 -0700 Content-Transfer-Encoding: 7bit Derek, >> As for LSPs, we have two options---use link-specific CSNs >> or rely on the ISIS SNs. The choice between the two is essentially >> the choice between attack prevention and attack detection. >> CSNs will provide attack prevention, as the attacker will not >> be able to replay old LSPs. ISIS SNs will not save us from > I have not follow this thread closely so my comment may be just > a misunderstanding. > I don't expect there is any synchronization of CSN in the whole > network. So it is possible for a interface in the network has much larger > CSN for another interface in the same network. As a result, one can caputure > the LSP on the interface with larger CSN and replay it on the interface > with lower CSN and there is still no attack prevention. Yes, a very interesting observation. Two moments here, however. First, this assumes that the two segments are configured with the same secret key. Second, wouldn't the attacker have to establish an adjacency with some router on the segment before the replayed LSP is accepted? I don't recall the ISIS spec actually saying so, but I would suspect the implementations to do this check. Thanks, Derek! Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 01:59:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22529 for ; Mon, 2 Jul 2001 01:59:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA58495; Sun, 1 Jul 2001 23:01:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA58483 for ; Sun, 1 Jul 2001 23:00:11 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f625tVw69268 for ; Sun, 1 Jul 2001 22:55:31 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 4371826BD1A; Sun, 1 Jul 2001 22:57:10 -0700 (PDT) To: isis-wg@juniper.net Subject: Re: [Isis-wg] Derek's proposal for MTU discovery in IS-IS In-reply-to: Mail from Derek Yeung dated Sun, 01 Jul 2001 17:44:32 PDT <3B3FC3F0.3AFB80CA@procket.com> From: Naiming Shen Message-Id: <20010702055710.4371826BD1A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 01 Jul 2001 22:57:10 -0700 I once helped a big ISP troubleshooting a network problem, the isis adjacency wouldn't come up. The link was an ATM interface, the ip level seemed fine. Then it was found if the IIH was never padded, the adjacency came up. It turned out to be the ATM link provider had some rate-limiting mechanim inside the ATM network, the 4470 bytes of padded IIH on this port just happen to exceed their limit, so some of the ATM cells got dropped with large packet size. I forget in this case if it was a misconfiguration by the ATM network provider or the ISP did agree to buy the link with this limitation, the point here is, without the isis padding(the first IIH), that ISP might never notice this problem, then some of their BGP packets could be dropped also over that link. Yes, isis have cuased lots of "troubles" for vendors and ISPs due to this padding issue. in most of the cases, IMHO, isis is only the messenger. if it is shot, unfortunately, there will be no other messengers around who can detect such a problem in earlier stage. With all this said, I do sympathize with the isis developers, they have to prove their innocence every time a bug is filed, because the bugs usually have the title of "Urgent: IS-IS does not work over .....";-) thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 07:16:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06174 for ; Mon, 2 Jul 2001 07:16:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA59937; Mon, 2 Jul 2001 04:18:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA59925 for ; Mon, 2 Jul 2001 04:17:10 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f62BCSw73912 for ; Mon, 2 Jul 2001 04:12:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp19.cisco.com [144.254.108.86]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA17710; Mon, 2 Jul 2001 12:13:55 +0100 (BST) Message-Id: <4.3.2.7.2.20010702112745.032ef3b8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Derek Yeung From: mike shand Subject: Re: [Isis-wg] Derek's proposal for MTU discovery in IS-IS Cc: Ran Atkinson , isis-wg@juniper.net In-Reply-To: <3B3FC3F0.3AFB80CA@procket.com> References: <200106262310.f5QNA9U28078@redd3174.procket.com> <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 12:14:31 +0100 At 17:44 01/07/2001 -0700, Derek Yeung wrote: > Sorry for the late reply. > > Given enough interest, I can send out a draft in a week or so for > the MTU TLV >for IIH. How does this compare with the proposal which was originated in the Sonet Interoperability Forum and is being incorporated in ISO/IEC 10589 second edition? > Going through the thread, it appear to me the problem this new > TLV does not >solve is the FDDI-Ethernet type bridged network Radia mentioned. IMHO, >this network model >is broken in nature and hopefully it is not wide-spread enough to render >the suggestion useless. > > For Henk's comment - > > > In theory there are two more problems that can be detected early > > when the IIH is really padded to mtu-size. > > 1) bit errors or packet corruption that has a higher probability to > > occur with larger packets. Supposedly this is something from the > > past when transmissions were over copper, not fibre. > > I suppose it can be better detected/solved by > checksum/authentication. Well, no it can't, because it only happens when you have big packets. (Naiming gives an example in his reply). > > 2) bugs. interfaces that have their MTU off by 1 (or 4. (I have seen > > these bugs in cisco)). > > If the MTU is off such that both side does not match, it would be > fine >as adjacency is not found and this problem should be caught in early >developement. > > > or routers running out of huge buffers. > > stuff like that. > > Given that only the first IIH is padded, it is not helpful to detect >temporary outage of huge buffer. If the outage is permanent, the system >should >probably detect it and take some action. Well its only pt-pt links that only have the first IIH padded, and even that is an anachronism, since it was designed for connection oriented data links (such as HDLC I-frame service). Running over PPP (using HDLC UI-frames) doesn't have the right properties, so it should probably be always padded (or not at all if that what you want). > I agree with Henk that these two issues is not big deal though. Yes, I agree its not a big deal. >Cheers, >- Derek > > >Ran Atkinson wrote: > > > > Henk's historical analysis is extremely helpful. > > I hope we are all now focused on the problem at hand. > > Thanks much for the detailed analysis and history. > > > > At 19:27 26/06/01, Derek Yeung wrote: > > > OSPF have the same problem. OSPF solves the problem by putting the > > >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable > > >to put a TLV in IIH to carry the MTU instead of padding IIH to full > > >MTU size ? > > > > This seems like a simpler approach. The concept is known to > > work (thanks to OSPF). Why don't we just try this to solve the > > immediate IS-IS issue that Henk outlined ? Oh, and if we do this, > > it might not hurt to add a MIB object or two to make MTU mismatches > > discovered by IS-IS easy for operators to grab via SNMP. > > > > Quite separately, I'll probably draft up an "IP over > > Jumbogram Ethernet-II Framing" spec that just documents the > > as deployed IP/Ethernet practice, as an Informational RFC. I don't > > see that as an IS-IS WG work item, in no small part because IS-IS > > does not use Ethernet-II Framing. > > > > Cheers, > > > > Ran > > rja@inet.org > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 14:49:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15619 for ; Mon, 2 Jul 2001 14:49:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA61735; Mon, 2 Jul 2001 11:52:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA48509 for ; Sat, 30 Jun 2001 07:02:05 -0700 (PDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5UDvgw50130 for ; Sat, 30 Jun 2001 06:57:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 931118266E for ; Sat, 30 Jun 2001 09:59:04 -0400 (EDT) Message-Id: <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: isis-wg@juniper.net From: RJ Atkinson Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <10773060375.20010629200609@nexsi.com> References: <3140683129.20010629110628@nexsi.com> <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> <3140683129.20010629110628@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 30 Jun 2001 09:55:02 -0400 At 23:06 29/06/01, Alex Zinin wrote: >(I belive Jerome Etienne has a paper on a similar > mechanism for OSPF somewhere.) With all respect to the author, that proposal creates more security problems than it solves. It changes how one engages in an active attack, but does not increase the attacker's work function. Further, the author of proposal seems to (erroneously) think the goal of OSPF MD5 is perfect security, which it never was. The goal of OSPF MD5 and RIP MD5 was to make a plausible (not necessarily optimal) engineering tradeoff between increased work function for the attacker and implementation/deployment complexity -- and to eliminate purely passive attacks as a significant threat. > 1. SeqNum roll back does not seem to be a problem to me, > see item 4 below. > > 2. In the new TLV, introduce the generation ID (16 or 32 bits). > > 3. The implementations guarantee that the generation ID is > incremented with each reboot using one of multiple methods, > e.g., reading, incrementing and writing it back to nvram > on each boot, or using seconds since somewhen, or a calendar > clock, whatever is better suited for a specific system. > > 4. The CSN is incremented after each packet. If a system sends > 10 packs per sec, 32-bit space will give us more than 10 > years of a key lifetime. We may want to increase it though, > if we seriously consider subsecond hellos. > > 5. The receiving side checks that the CSN in the packet is > _greater_ than the locally stored value. > > Vernon did not seem to like the scheme, because of the possible > issues with NVRAM, and calendar clock... I'm with Vernon. The attack changes, but it is not obvious that the new attack would be any more work, just different. To be useful, a security mechanism needs to visibly increase the work that an attacker must make against the system being attacked, IMHO. IMHO, the likely next logical improvement step would be to move to real digital signatures (as different from a keyed hash function). I doubt there is much interest in implementing or deploying that, taking the existence of OSPF with Digital Signatures as a datum. Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 19:52:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24314 for ; Mon, 2 Jul 2001 19:52:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA62917; Mon, 2 Jul 2001 16:53:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA62169 for ; Mon, 2 Jul 2001 13:37:16 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f62KWTw06678 for ; Mon, 2 Jul 2001 13:32:29 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id NAA08882; Mon, 2 Jul 2001 13:40:51 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1385397280.20010702134050@nexsi.com> To: RJ Atkinson CC: isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> References: <3140683129.20010629110628@nexsi.com> <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> <3140683129.20010629110628@nexsi.com> <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 13:40:50 -0700 Content-Transfer-Encoding: 7bit Ran, To make sure we're on the same page, I'm not looking at this as an attempt to improve the authentication mechanism from the crypto perspective (as you mentioned, Digital Signatures do not seem to be of real interest to people), but as an attempt to prevent very simple replay attacks _within_ HMAC and try to fix those well-known problems with the sequence numbers that you mentioned and Vernon elaborated on. -- Alex Zinin Saturday, June 30, 2001, 6:55:02 AM, RJ Atkinson wrote: > At 23:06 29/06/01, Alex Zinin wrote: >>(I belive Jerome Etienne has a paper on a similar >> mechanism for OSPF somewhere.) > With all respect to the author, that proposal creates more > security problems than it solves. It changes how one engages in an > active attack, but does not increase the attacker's work function. > Further, the author of proposal seems to (erroneously) think the > goal of OSPF MD5 is perfect security, which it never was. The goal > of OSPF MD5 and RIP MD5 was to make a plausible (not necessarily optimal) > engineering tradeoff between increased work function for the attacker > and implementation/deployment complexity -- and to eliminate purely > passive attacks as a significant threat. >> 1. SeqNum roll back does not seem to be a problem to me, >> see item 4 below. >> >> 2. In the new TLV, introduce the generation ID (16 or 32 bits). >> >> 3. The implementations guarantee that the generation ID is >> incremented with each reboot using one of multiple methods, >> e.g., reading, incrementing and writing it back to nvram >> on each boot, or using seconds since somewhen, or a calendar >> clock, whatever is better suited for a specific system. >> >> 4. The CSN is incremented after each packet. If a system sends >> 10 packs per sec, 32-bit space will give us more than 10 >> years of a key lifetime. We may want to increase it though, >> if we seriously consider subsecond hellos. >> >> 5. The receiving side checks that the CSN in the packet is >> _greater_ than the locally stored value. >> >> Vernon did not seem to like the scheme, because of the possible >> issues with NVRAM, and calendar clock... > I'm with Vernon. The attack changes, but it is not obvious > that the new attack would be any more work, just different. To be > useful, a security mechanism needs to visibly increase the work > that an attacker must make against the system being attacked, > IMHO. > IMHO, the likely next logical improvement step would be to > move to real digital signatures (as different from a keyed hash > function). I doubt there is much interest in implementing or > deploying that, taking the existence of OSPF with Digital Signatures > as a datum. > Ran > rja@inet.org > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 19:55:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26423 for ; Mon, 2 Jul 2001 19:55:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA62953; Mon, 2 Jul 2001 16:57:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA62335 for ; Mon, 2 Jul 2001 14:20:56 -0700 (PDT) Received: from redd2222.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f62LG9w15265 for ; Mon, 2 Jul 2001 14:16:09 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd2222.procket.com (8.11.0/8.9.3) with ESMTP id f62LHlb06828; Mon, 2 Jul 2001 14:17:47 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B40E4FB.E6613FC6@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Omer Sali , isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> <143254621456.20010701223210@nexsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 14:17:47 -0700 Content-Transfer-Encoding: 7bit Alex Zinin wrote: > > Derek, > > >> As for LSPs, we have two options---use link-specific CSNs > >> or rely on the ISIS SNs. The choice between the two is essentially > >> the choice between attack prevention and attack detection. > >> CSNs will provide attack prevention, as the attacker will not > >> be able to replay old LSPs. ISIS SNs will not save us from > > > I have not follow this thread closely so my comment may be just > > a misunderstanding. > > > I don't expect there is any synchronization of CSN in the whole > > network. So it is possible for a interface in the network has much larger > > CSN for another interface in the same network. As a result, one can caputure > > the LSP on the interface with larger CSN and replay it on the interface > > with lower CSN and there is still no attack prevention. > > Yes, a very interesting observation. Two moments here, however. > First, this assumes that the two segments are configured with the same > secret key. I suppose we are talking about LSP here, which use the same key within one area. Second, wouldn't the attacker have to establish an adjacency with > some router on the segment before the replayed LSP is accepted? I don't recall The digest in LSP does not include the MAC header, so one can fake it, right ? To be clear, my comment is that adding CSN to LSP does not help much. Adding CSN to other ISIS packet type is a different issue. - Derek > the ISIS spec actually saying so, but I would suspect the implementations to > do this check. > > Thanks, Derek! > > Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 19:59:26 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29104 for ; Mon, 2 Jul 2001 19:59:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA63019; Mon, 2 Jul 2001 17:01:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA62969 for ; Mon, 2 Jul 2001 16:59:19 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f62NsVw26130 for ; Mon, 2 Jul 2001 16:54:31 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Tony Li'" Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 18:38:02 -0400 Tony - Looks good. Two minor nits. First, a quote An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect. An implementation MAY include HMAC-MD5 Authentication Information in PDUs even if it does not fully implement HMAC-MD5 authentication. This allows an implementation to generate authentication information without verifying the authentication information. This is a transition aid for networks in the process of deploying authentication. This indicates a difference between "implementing" and "fully implementing" and seems to contradict the "MUST discard" from first paragraph. It may be clearer if you talk about a protocol configuration that allows a "transition mode" or something along those lines. The text suggests that you run the checksum over the PDU. A brief look at the use of the term PDU in 10589 includes usage where the header is part of the PDU: you should make clear that you do not checksum the header. - jeff parker - axiowave networks - Ambivalent? Well, yes and no. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 20:25:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15931 for ; Mon, 2 Jul 2001 20:25:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA63153; Mon, 2 Jul 2001 17:27:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA63141 for ; Mon, 2 Jul 2001 17:26:31 -0700 (PDT) Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f630Lhw27067 for ; Mon, 2 Jul 2001 17:21:43 -0700 (PDT) X-JNPR-Received-From: outside Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id RAA16032; Mon, 2 Jul 2001 17:22:46 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15169.4182.825927.570597@alpha-tli.procket.com> To: Jeff Parker Cc: "'Tony Li'" , isis-wg@juniper.net Subject: RE: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 17:22:46 -0700 Content-Transfer-Encoding: 7bit Jeff, Thanks for the comments. | An implementation that implements HMAC-MD5 authentication and | receives HMAC-MD5 Authentication Information MUST discard the PDU if | the Authentication Value is incorrect. | | An implementation MAY include HMAC-MD5 Authentication Information | in PDUs even if it does not fully implement HMAC-MD5 authentication. | This allows an implementation to generate authentication information | without verifying the authentication information. This is a | transition aid for networks in the process of deploying | authentication. | | This indicates a difference between "implementing" and "fully implementing" | and seems to contradict the "MUST discard" from first paragraph. | It may be clearer if you talk about a protocol configuration that allows a | "transition mode" or something along those lines. I've reworded the second paragraph to read: An implementation MAY have a transition mode where it includes HMAC-MD5 Authentication Information in PDUs but does not verify the HMAC-MD5 authentication information. This is a transition aid for networks in the process of deploying authentication. | The text suggests that you run the checksum over the PDU. | A brief look at the use of the term PDU in 10589 includes usage where | the header is part of the PDU: you should make clear that you do not | checksum the header. Ummm... to be specific here, the intent is that you run the checksum over the IS-IS PDU, including the fixed length header. But not the link layer header. Is that not what you understood from the existing text? I've tried to reinforce this by specifically mentioning the "IS-IS PDU" vs. the "PDU". Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 22:05:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18941 for ; Mon, 2 Jul 2001 22:05:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA63630; Mon, 2 Jul 2001 19:08:13 -0700 (PDT) Received: from mail23.bigmailbox.com (mail23.bigmailbox.com [209.132.220.203]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA63618 for ; Mon, 2 Jul 2001 19:07:17 -0700 (PDT) Received: by mail23.bigmailbox.com (8.8.7/8.8.7) id TAA25598; Mon, 2 Jul 2001 19:04:11 -0700 Message-Id: <200107030204.TAA25598@mail23.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [211.99.83.153] From: "Navaneeth Krishnan" To: isis-wg@spider.juniper.net Subject: [Isis-wg] Mac Address Change.. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 19:04:11 -0700 Content-Transfer-Encoding: binary ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 2 22:07:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20159 for ; Mon, 2 Jul 2001 22:07:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA63660; Mon, 2 Jul 2001 19:10:16 -0700 (PDT) Received: from mail23.bigmailbox.com (mail23.bigmailbox.com [209.132.220.203]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA63639 for ; Mon, 2 Jul 2001 19:09:09 -0700 (PDT) Received: by mail23.bigmailbox.com (8.8.7/8.8.7) id TAA25786; Mon, 2 Jul 2001 19:06:02 -0700 Message-Id: <200107030206.TAA25786@mail23.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [211.99.83.153] From: "Navaneeth Krishnan" To: isis-wg@spider.juniper.net Subject: [Isis-wg] Mac Address Change.. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 19:06:02 -0700 Content-Transfer-Encoding: binary Hi All, This question is with specific reference to certain routers that allow configurable MAC addresses. what are the specific issues involved if MAC address change occurs, that any ISIS implementation needs to care about? Is there any reference materials/drafts available on MAC address change? thanks in advance Naren ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 3 09:43:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07344 for ; Tue, 3 Jul 2001 09:43:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA66753; Tue, 3 Jul 2001 06:45:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA66737 for ; Tue, 3 Jul 2001 06:44:06 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f63DdDw41908 for ; Tue, 3 Jul 2001 06:39:13 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Tony Li'" , Jeff Parker Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 3 Jul 2001 09:40:44 -0400 > | The text suggests that you run the checksum over the PDU. > | A brief look at the use of the term PDU in 10589 includes > | usage where the header is part of the PDU: you should make > | clear that you do not checksum the header. > > > Ummm... to be specific here, the intent is that you run the > checksum over the IS-IS PDU, including the fixed length header. > But not the link layer header. Is that not what you understood > from the existing text? I've tried to reinforce this by specifically > mentioning the "IS-IS PDU" vs. the "PDU". > > Tony Color me confused. My concern was the Remaining Lifetime field. You describe how to deal with that quite clearly in the second paragraph of section 2. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 3 14:44:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15383 for ; Tue, 3 Jul 2001 14:44:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA67934; Tue, 3 Jul 2001 11:46:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA67922 for ; Tue, 3 Jul 2001 11:45:04 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f63Ie9w54700 for ; Tue, 3 Jul 2001 11:40:09 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA19187; Tue, 3 Jul 2001 11:48:36 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <16885059168.20010703114834@nexsi.com> To: Derek Yeung CC: Omer Sali , isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B40E4FB.E6613FC6@procket.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> <143254621456.20010701223210@nexsi.com> <3B40E4FB.E6613FC6@procket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 3 Jul 2001 11:48:34 -0700 Content-Transfer-Encoding: 7bit Derek, > I suppose we are talking about LSP here, which use > the same key within one area. I was thinking about using per-interface CSNs and keys. I know it's not consistent with the nature of LSPs, i.e. the area significance scope, but it should work. Alex. > Second, wouldn't the attacker have to establish an adjacency with >> some router on the segment before the replayed LSP is accepted? I don't recall > The digest in LSP does not include the MAC header, so one can fake it, right ? > To be clear, my comment is that adding CSN to LSP does not help much. > Adding CSN to other ISIS packet type is a different issue. > - Derek >> the ISIS spec actually saying so, but I would suspect the implementations to >> do this check. >> >> Thanks, Derek! >> >> Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 3 17:15:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26395 for ; Tue, 3 Jul 2001 17:15:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA68574; Tue, 3 Jul 2001 14:17:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA68562 for ; Tue, 3 Jul 2001 14:16:38 -0700 (PDT) Received: from yarilo.pluris.com (host200.pluris.com [208.227.9.200]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f63LBfw60665 for ; Tue, 3 Jul 2001 14:11:41 -0700 (PDT) X-JNPR-Received-From: outside Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA01578; Mon, 2 Jul 2001 13:05:25 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 13:05:25 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A4C1@avalon.pluris.com> From: Les Ginsberg To: "'mike shand'" , Derek Yeung Cc: Ran Atkinson , isis-wg@juniper.net Subject: RE: [Isis-wg] Derek's proposal for MTU discovery in IS-IS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 13:05:21 -0700 > > How does this compare with the proposal which was originated > in the Sonet > Interoperability Forum and is being incorporated in ISO/IEC > 10589 second > edition? > > > The SIF proposal is concerned with advertising originatingLSPBufferSize. The TLV appears in an LSP and has area wide(L1) or domain-wide(L2) implications. The MTU discovery proposal TLV appears in an IIH and has immediate significance only between neighbors on a link. It is certainly true that there is a relationship between originatingLSPBufferSize and link MTU size in that the MTU size on ALL links on which LSPs will be propagated must be >= originatingLSPBufferSize. In that sense the two proposals complement each other - though the use of padding appropriately applied also serves this purpose. For those who are interested, the SIF proposal was posted to the list back in 1998 and (amazingly) is still available at: ftp.juniper.net:pub/isis/lspsize.PDF It is allegedly still available on the SIF website but I found that link to be stale. It should also be mentioned that a minor change to the proposal above has been made to resolve the TLV conflict with draft-ietf-isis-wg-snp-checksum-01.txt. The two TLVs (12 and 13) mentioned in the document have been combined into a single TLV(14). The determination of whether the size being advertised is L1 or L2 is determined by the LSP type in which the TLV is found. (I have been waiting for formal commitment for this change to be incorporated into the latest draft of ISO 10589 before announcement - guess I have done it now.) Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 3 18:07:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00666 for ; Tue, 3 Jul 2001 18:07:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA68846; Tue, 3 Jul 2001 15:09:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA68796 for ; Tue, 3 Jul 2001 15:03:28 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f63LwUw62520 for ; Tue, 3 Jul 2001 14:58:31 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25569; Tue, 3 Jul 2001 17:59:10 -0400 (EDT) Message-Id: <200107032159.RAA25569@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: isis-wg@juniper.net From: The IESG Subject: [Isis-wg] Document Action: IS-IS Transient Blackhole Avoidance to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 17:59:09 -0400 The IESG has approved the Internet-Draft 'IS-IS Transient Blackhole Avoidance' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Abha Ahuja and Rob Coltun. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 06:54:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06715 for ; Thu, 5 Jul 2001 06:54:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77659; Thu, 5 Jul 2001 03:57:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77647 for ; Thu, 5 Jul 2001 03:56:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65ApUw95329 for ; Thu, 5 Jul 2001 03:51:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06369; Thu, 5 Jul 2001 06:52:33 -0400 (EDT) Message-Id: <200107051052.GAA06369@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 06:52:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : J. Kaplan et al. Filename : draft-ietf-isis-ext-eth-01.txt Pages : Date : 03-Jul-01 This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 14:44:55 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23295 for ; Thu, 5 Jul 2001 14:44:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79502; Thu, 5 Jul 2001 11:47:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79490 for ; Thu, 5 Jul 2001 11:46:51 -0700 (PDT) Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65IfZw10388 for ; Thu, 5 Jul 2001 11:41:35 -0700 (PDT) X-JNPR-Received-From: outside Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id KAA06521; Thu, 5 Jul 2001 10:39:18 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eZX0VkAf8B" Content-Transfer-Encoding: 7bit Message-ID: <15172.42561.62675.380472@alpha-tli.procket.com> To: isis-wg@juniper.net X-Mailer: VM 6.92 under Emacs 20.5.1 Subject: [Isis-wg] forwarded message from Internet-Drafts@ietf.org Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 5 Jul 2001 10:39:13 -0700 --eZX0VkAf8B Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Folks, Please note the revised ID on Extended Frame Support. Could we please get comments by 5:00PM PDT July 13? Again the proposal is to ask to have this published as an Informational RFC. Thanks, Tony --eZX0VkAf8B Content-Type: message/rfc822 Content-Description: forwarded message Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Return-Path: Received: from slr.procket.com (slr.procket.com [10.1.1.5]) by miata.procket.com (8.11.1/8.11.1) with ESMTP id f65B04417788; Thu, 5 Jul 2001 04:00:04 -0700 (PDT) Received: from slr.procket.com (localhost [127.0.0.1]) by slr.procket.com (8.11.1/8.9.3) with ESMTP id f65B04I12234; Thu, 5 Jul 2001 04:00:04 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [10.1.1.1]) by slr.procket.com (8.11.1/8.9.3) with ESMTP id f65AxLI12068 for ; Thu, 5 Jul 2001 03:59:21 -0700 (PDT) X-Confidential: Procket Confidential/Need to know Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by miata.procket.com (8.11.1/8.11.1) with ESMTP id f65AxL417744; Thu, 5 Jul 2001 03:59:21 -0700 (PDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77663; Thu, 5 Jul 2001 03:57:45 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77647 for ; Thu, 5 Jul 2001 03:56:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65ApUw95329 for ; Thu, 5 Jul 2001 03:51:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06369; Thu, 5 Jul 2001 06:52:33 -0400 (EDT) Message-Id: <200107051052.GAA06369@ietf.org> Reply-to: Internet-Drafts@ietf.org X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk Errors-To: isis-wg-external-admin@Procket.com X-BeenThere: isis-wg-external@mailist.procket.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: From: Internet-Drafts@ietf.org Sender: isis-wg-external-admin@Procket.com To: IETF-Announce: ; Cc: isis-wg@juniper.net Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-01.txt Date: Thu, 05 Jul 2001 06:52:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : J. Kaplan et al. Filename : draft-ietf-isis-ext-eth-01.txt Pages : Date : 03-Jul-01 This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.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 --eZX0VkAf8B-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 16:47:51 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27147 for ; Thu, 5 Jul 2001 16:47:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80110; Thu, 5 Jul 2001 13:50:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA69720 for ; Tue, 3 Jul 2001 18:43:49 -0700 (PDT) Received: from mail23.bigmailbox.com (mail23.bigmailbox.com [209.132.220.203]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f641cpw67779 for ; Tue, 3 Jul 2001 18:38:51 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail23.bigmailbox.com (8.8.7/8.8.7) id SAA11092; Tue, 3 Jul 2001 18:40:25 -0700 Message-Id: <200107040140.SAA11092@mail23.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [211.99.83.153] From: "Rajesh Hegde" To: henk@procket.com Cc: isis-wg@juniper.net Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 3 Jul 2001 18:40:25 -0700 Content-Transfer-Encoding: binary Hi, What to we do for supporting ethernet jumboframes ? Do we go ahead with padding hellos to mtu-size ? What will happen to the LSP buffersize ? Does it need to be increased beyond 1492 bytes? Or else try to establish the adjacency with small hellos without bothering to the padding of hellos to mtu-size ? thanks and Regards, Rajesh > Back to ISIS, do we really need LSP datagrams with sizes over 1492? No, ISIS doesn't need larger LSPs. The problem was this: *) Some router vendors support "jumboframes" over GE. *) IP packets are encapsulated in EthernetII frames. (*) *) Encapsulation of EthernetII frames in such jumboframes is easy. *) ISIS sends hellos padded to mtu size, to do early detection of mtu mismatches, and other problems. *) Some ISPs wanted this early detection to keep working even over GE with jumboframes. *) Therefor, ISIS must send hellos padded up to "jumboframe mtu" *) ISIS packets are encapsulated in 802.3/802.2 frames. (*) *) 802.3/802.2 frames can not be longer than 1500 bytes. *) Therefor ISIS can not use jumboframes. *) To solve this problem (and IMHO only this problem of padded hellos) draft-ietf-isis-ext-eth-00.txt was written. Possible solutions: 1) Change ethernet specs. 2) Make IS-IS use EthernetII encapsulation. 3) Make IS-IS use IP encapsulation. 4) Forget about padding IS-IS hellos to mtu-size. It seems proposal 1) encountered more opposition than envisioned. :-) Proposals 2) and 3) are gonna introduce lots and lots of interoperability problems. Not worthwile, IMHO. Doing 4) seems a nice and simple solution. And it has the benefit that ISIS will keep working on bridged networks of GE and other flavors of Ethernet. I never understood why ISPs insisted on keeping ISIS to pad its hellos to mtu-size. OSPF sends small hellos, and that does not seem to give many more headaches. henk. -- PS.(*) I know this terminology is not the proper lingo anymore. If you know how to call those 2 encapsulation methods, please educate me. Thanks. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 16:49:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27174 for ; Thu, 5 Jul 2001 16:49:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80132; Thu, 5 Jul 2001 13:52:24 -0700 (PDT) Received: from mail10.bigmailbox.com (mail10.bigmailbox.com [209.132.220.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA70705 for ; Tue, 3 Jul 2001 22:41:57 -0700 (PDT) Received: by mail10.bigmailbox.com (8.8.7/8.8.7) id WAA10040; Tue, 3 Jul 2001 22:38:36 -0700 Message-Id: <200107040538.WAA10040@mail10.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [211.99.86.158] From: "Rajesh Hegde" To: henk@procket.com Cc: isis-wg@spider.juniper.net Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 3 Jul 2001 22:38:36 -0700 Content-Transfer-Encoding: binary Hi, What to we do for supporting ethernet jumboframes ? Do we go ahead with padding hellos to mtu-size ? What will happen to the LSP buffersize ? Does it need to be increased beyond 1492 bytes? Or else try to establish the adjacency with small hellos without bothering to the padding of hellos to mtu-size ? What will happen to LSP bufer size in case of data link interfaces having link MTU size lesser than 1500 bytes (for ex. DC interfaces) ? Thanks and Regards, Rajesh ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 16:51:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27214 for ; Thu, 5 Jul 2001 16:51:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80159; Thu, 5 Jul 2001 13:54:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA76766 for ; Thu, 5 Jul 2001 00:49:16 -0700 (PDT) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f657i3w92332 for ; Thu, 5 Jul 2001 00:44:04 -0700 (PDT) X-JNPR-Received-From: outside Received: from ns (mjyang.etri.re.kr [129.254.194.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NT69G3G4; Thu, 5 Jul 2001 16:43:15 +0900 Message-ID: <006701c10528$fc776b80$37c2fe81@etri.re.kr> From: "mjyang" To: Organization: ETRI MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0063_01C10574.6C46A980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Isis-wg] [Question] About ISIS packet format? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 5 Jul 2001 17:03:33 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C10574.6C46A980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0064_01C10574.6C46A980" ------=_NextPart_001_0064_01C10574.6C46A980 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLi4NCg0KV2UgYXJlIGRldmVsb3BpbmcgSVMtSVMgcm91dGluZyBwcm90b2NvbC4NCldl IGhhdmUgc29tZSBxdWVzdGlvbiBhYm91dCBJU0lTLg0KSW4gSVNJUyBmb3IgSVAsIEkgd2FudCB0 byBjb25maXJtIElTSVMgcGFja2V0IGVuY2Fwc3VsYXRpb24gZm9ybWF0Lg0KSXMgdGhlIGZvbGxv d2luZyBmaWd1cmUgcmlnaHQ/DQoNCkF3YWl0aW5nIHRoZSBwbGVhc3VyZSBvZiB5b3VyIHJlcGx5 LiANClJlZ2FyZHMsDQogDQpNLkouWWFuZy4uDQoNCi0tLS0tLS0tLS0tLS0tLS0tDQpNaWp1bmcg WWFuZyAvIEVUUkkgDQpURUw6ICs4Mi00Mi04NjAtNDkyMiANCkZBWDogKzgyLTQyLTg2MC01NDQw IA0KRS1tYWlsOiBtanlhbmdAZXRyaS5yZS5rciANCg0K ------=_NextPart_001_0064_01C10574.6C46A980 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC4u PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPldlIGFy ZSBkZXZlbG9waW5nIElTLUlTIHJvdXRpbmcgcHJvdG9jb2wuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+V2UgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IElTSVMuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+SW4gSVNJUyBmb3IgSVAsIEkgd2FudCB0byBjb25maXJtIElT SVMgcGFja2V0IGVuY2Fwc3VsYXRpb24gDQpmb3JtYXQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+SXMgdGhlIGZvbGxvd2luZyBmaWd1cmUgcmlnaHQ/PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mj5Bd2FpdGluZyB0 aGUgcGxlYXN1cmUgb2YgeW91ciByZXBseS48L0ZPTlQ+IA0KPERJVj48Rk9OVCBzaXplPTI+UmVn YXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5NLkouWWFuZy4uPEJSPjwvRk9OVD48L0ZPTlQ+PElNRyBhbGln bj1iYXNlbGluZSBhbHQ9IiIgDQpib3JkZXI9MCBoc3BhY2U9MCANCnNyYz0iY2lkOjAwNjIwMWMx MDUyOCRmYzRlMzhhMCQzN2MyZmU4MUBldHJpLnJlLmtyIj48L0RJVj48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tPEJSPk1panVuZyBZYW5nIC8gRVRSSSA8QlI+VEVM OiANCis4Mi00Mi04NjAtNDkyMiA8QlI+RkFYOiArODItNDItODYwLTU0NDAgPEJSPkUtbWFpbDog PEEgDQpocmVmPSJtYWlsdG86bWp5YW5nQGV0cmkucmUua3IiPm1qeWFuZ0BldHJpLnJlLmtyPC9B PiANCjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0064_01C10574.6C46A980-- ------=_NextPart_000_0063_01C10574.6C46A980 Content-Type: image/gif; name="ISISFrameFormat.GIF" Content-Transfer-Encoding: base64 Content-ID: <006201c10528$fc4e38a0$37c2fe81@etri.re.kr> Content-Transfer-Encoding: base64 R0lGODdhvwPPAvcAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88C QAj/AAMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXQoTgNOnUKNKnUq1qtWrWLNqrTpyq9evYMOK tdp1rNmzaM8yXcu2rdu3SwEglFvQ6UC6BO0mxBuR70G9AejK5Qu1ol+Ph+8aBHwYcN3EQiFvhNwY b+W9kn9mhsu5s+fPoDtu5jiaZ2mLpzE6nig1r0DBigPHppiatsnVhjHnfaqxdujfwIMLdzs4qmvZ yGEHHvx6uXLavB/HZn43Ouuuzq0nb759+XbeuIf6WpZYvPB07srtwgY/3mb74fDjy59P3+H7+qLx u9fPv7///wCuFF6AF91HIEMDHqjgggw26KBCBv4XIYATPmjhhRhmqF+CAVYYHIcahijiiCQ26CFx /p1Y4oostrDoInwgdqaiZjO+aOONOOYIXI038fhSjDoGKeSQREoomHamTYWTecgV6eSTUEaZUVpU VmnllVhmqeWWSHKX3Vx1ndfdc+Wdx16TUqap5pohnUZYlxCymZSPctZp55050bkYZ2/iFh11ZHpp 2Ziv6RmToXgmquiit2XnWHroFfqdXogySpqlmGaq6aYnVcrpp6CGKuqHo5Zq6qmo9udpqqy26uqr KK0K66y01mqrfbfmqorrrrxe2uuvwAYrrJfDFmvssaNSxSJhcS7kW4KDIiutsFxWa+212Gar7bZM Tuvtt4feJmutQE4J7rnoCugos4QmB6hz3sHVZ2XrRWpvk++6y2d52kE65rvgpSvwwCJ5Wu7ABxdI 8MIMT8ntwxBHLPHE1jZs8cUYZ6zxxhx37PHHIIcs8sgkl2zyySg4p6zyyiy37PLLMMcs88w012zz zTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+3001BHLfXUVFcxbfXVWGet9dZcd+3112CHLfbY ZJdt9tlop6322my37fbbcMct99x012333XjnrffefCr37fffgAcu+OCEF2744YgnrvjijDfu+OOQ Ry755JRXbvnlmGeu+eacd+4o+eeghy766KSXbvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3 7qX778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUy/gXY+rBWyh1f6GW/fayYX8knLgWPJf44aOf WMJ5YreY+trDS9m4H9FfPX7rU6r9n/F3b9ij+2NMdSJkqPmth1L6Ix/7HjO+vcymN+5jYHP+lEBo VahLAXMUBO9XJPOQz1kghE6/soc+DdqmYBRsT2YWuJsGVgd8KVQYChGoQghd0DjpswwLHci1QSJ5 8FHzktSRwIemvqymTPHTIQHLQsPdtHCIQ5Sf/RDDRBdKaoBQvOKZjjLFHmKqi/QB44bE6EWPkdF6 OTpjGWWmRqS0kYtvXGPR4qgTOi5Jjo+zo0v0mJId4jFyfGyTZwL5x8ARMjdwLCTzuEIjP1axW3tU DyS390FF0qw0KUzYITVFr/4xEINbLIxxRjjK4lgSXZhsYl/kRUNHHmeV8jrl1X5Yw2YRR5XdE1+0 kqhLIfJJloRWo6UTsejLePHPjMBMZpiUyUwHbbKZ0JTJM6NJzZZMs5rYjFU2t1mfa3Lzm/UDpzh/ M8kR+aVPxELS+mYTxT3hS4Lt+tI4W2Qwby7KlQ+x5zzvJEzy2JCV48MnsfK5rxj6k4f7zFg/r0jJ YjZRoHnC5Z56KagSyvN7b8HhCJ/o0AbqM6EncqrnxyCKIJCa9KQoTalKV8rSlrr0pTCNqUxnStOa 2vSmOM2pTnfKIdOe+vSnQA2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnSiHVqlr1qljNqla3ytWu evWrYA2rWMdK1rKa9axoTata18of1ra69a1wjatc50rXutr1rnjNq173yte++vWvgA2sYB0HS9jC GvawiE2sYhfL2MY69rGQjaxkJ0vZylr2sqmYzaxmN8vZznr2s6ANLeRW9dFXgkSkboxgWVL7WMo8 MFAPXOZBxYSeXb7zOuYDUzoFZdoXslaQ/kMTbAfqW6OUdqmu3e1tiRtbgh6HXTrsLW6BG1zovvZ6 c1LtK62r3Pf9trGk/W44S+JKdum2iKrRbps81JjtNne64O2UeKlI3iVe173Lhe94SQLR9rIzP60V 7gkROt3n6Ku77ymggPUrnfnmx7ywPJ+DfhPLvQWLaVDnfK9zTUsmCA/4tBYuor/Ct0yS7hE7EM5w d0j83OMyl8Ly5aJ6T+viF09GXBMWLX9rnN2Q6hh/HYySiX8cyzQOachE/hCP72ijJSc5oiRysjSl /OTIZIjKKkFylUWEZf6aaMub6jJ9JQRmVGk5x0ou863EPNs0q4eZWsNhc3Df/C05uxNFdL7YmaUZ FzvnGUqXaaSSepS/P7Ns0D5pDaHLaWiUYQUoe/YeI5vy3zvb2M9bDi8y77wZFberw7b1l4Eb3aiG mDc1mBYSGT1M6h6Vz8a25FiqW33jUmcUvzKMMJ5prSBN31rDvA3ULjF8LzvPmtfpZfWrzyuf0Rwb kcg7JlCFPTziCud3Y8+O9odnjLFsaztU3v421sIt7mCWO3bkPvfU0q3uqLG73U97N7ybJu95L63e 9k4avvOAfbR983uO/0advwPeM7IQ3HOKXpGnjYk9S/9XgPGiLfcEiFGGHhxHkW42hyOVr/sO+17N 5W61YY1Z1HYs48C+uLrqO1KDqXwmJpe1y18eLmWb+p9F5m1629yWiic41jS3ZohVLOwSG1u67i26 zlk83FsOvcTBhnrQf4TjMJZU2jMkn7rQWW7GrGt95Ttuua2/Tvaym/3saE+72tfO9ra7/e1wj7vc GOdO97rb/e54z7ve9873vvv974APvOAHTxn4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpbGP7ymM+8 5jfP+c57/vOgD73oR0/60pv+9BeoT73qV8/61rv+9bCPvexnT/va2/72uBbPve53z/ve+/73wA++ 8IdP/OIb//jIFk++8pfP/OY7//nQj770p0/96lv/+tgWz772t8/97nv/++APv/jHT/7ym//86BVP v/rXz/72u//98I+//OdP//rb//4V+M+//vfP//77//8AGIACOIAEWIAGF3iACJiACriADNiADviA EBiBEjiBFFiB/6bia0WhYFwnY7kVdhzoWBhIFBrogR8IYhuYgZCVXPgyXNACbfqjRRtHcgS2X5zm W8NWaGhmLtVlg+w0PzlYWCoYcenkbNs2TIphYLYFESNoaUdkhNj1g7kmW0IoXJ1WYwOnUkH4XMwm hUp4c9+BdLpGg1xIW2M4hSLIbcmVhcWFggFWXdESXZfmgsWFhGDYhR3IaW84h09YgmLYgxKXhGt4 hm1IXlCIGlUHbehlgzOyhCi0Qdv1cTsHgjFmXNyGGPY1UBC3gpdogiQYhYF4bUWoWCEoHpUoGpsY RLcFiHZIXaulgwi1iCk4iWzIio1oiB6nc6q4YZzYipGYPpVWa0OSaHPO0mm2uGIviGCheCnCiHMS Voi5sYy6EY2UGGDU9iZO1E7MYSA3GCZ0KINbSEXV6ITfQ3EoR4jmE45rOI4YVo6lnmhY08ZRRLSO x6iNIVQvKbds4ZRi1nFMOZQePKZg+lhC8uiPzhhY73hh9uJBS8dgEJdivZiPMShqDfUvPSZIDvlp E0mQfLhYo2hld1iLGwlgnSiIIEgxJukVj3SSKjlpNLaSLoloKneFLCGTTUGTJSdkbMKOc6eT/GGT 2vR5PrmLPmR6QekrR7Z6PBlnQZKUiFeUxfgiTNl4TslzJRKVTJE3lbpoTljZblsJdFeGfFbJFF05 Z8o3lvfYIdQ3ll0ZlqzHlh55IG4Je04ZlHFJe3VZR0aifjQ5cHfpe3zZTfbXl5QWH2bZlPNBboVx KZUwQk6JeZXelmqCmX3PZmyNuXmRSYt9ZoHeGJLTqJkOJ5ZKUZlt+Y8GB2me2WaVtGgJVxNHJJq3 t5o9AZMwJ0quiXvKAmmM9iOyeZoitJs7kZozyZIntpD39Y3gB5ysqZq3SXXEiYnDREFPlI16WHGU bNeR3baDQIdOmoiL8DRi1SmL2IadBCZyxkRc5Lli3+mFzTmDGrNqdZh3boJrV3dyh4KcdhefZ0mW 7Wmby1ZL9Pma4MkWp6Ya43GZIll71hkX8jlBcMge09ZwL3R0ADp2Pfeeb/iCkOguTVehE2qOvwZr CRR1S5cvVsShtneQRhRCh6meZAag6Ghx6niEiahkkmGfhD/JnwGpRMHGj7UJmC4akQmZket5nR3q ZZt2oi+ZpEq6pNvCmzDnpJzSo1AaoFOqKFJapUaKpYxypVqKmV1qJ1wq+qVjJqb8RKaJEqZm6ohp 6mNrWido2qZPCadp8qZyymB1+iR0eqerqKeAb8anUpKnfjqfgRpkg+okgFqoxomoGKeoaVSajKpw y8llOPQ//pWosBmYlxoiC1eGnOqV+Tl/k1qVsjVyIuZd+zNB14NLB2RKeRh+NupMo1pszlmDHKef 57mhruoil0qbxERJDyVJvDpALRSdkhRxBp7KVjGHbV7HeMnansu6eM2qUM+qeNHabdOaeNWqZ9dq mCeorBQKrSGWTyskoUOqhAVKmeFqHysEeSgKo9aIjZ4koAvqi1oErFQIh8WUUe0qhEB0YPTqeO3K JDx6URZnojOKixj6iy6Ui5mZo8L6Tgp5sIcXsEGqoaJGrhIbohCrsJ92rL1BsRhJsOjJrIeocYKa Its6sSULIxZUlOx4qCd3la0W87LsurLO+q3UarPSirPYqrPWyrOPGrRCO7REW7RGe7RIm7QTSru0 TNu0Tvu0UBu1Uju1VFu1VhV7tVibtVq7tVzbtV77tWAbtmI7tmQUW7Zme7Zom7Zqu7Zs27Zu+7Zw G7cTcju3dFu3dnu3eJu3eru3fNu3fhT7t4AbuII7uIRbuIZ7uIibuIq7uBOM27iO+7iQG7mSO7mU W7mWe7mYEpu5mru5nNu5nvu5oBu6oju6pBRbuqZ7uqibuqq7uqzbuq77urAbuxKyO7u0W7u2e7u4 m7u6u7u827sSvvu7wBu8wju8xFu8xnu8yJu8Esq7vMzbvM77vNAbvdI7vdRbvRLWe73Ym73au73c 273e+73gG74Q4ju+5Fu+5nu+6Ju+6ru+7BLbvu77vvAbv/I7v/Rbv/Z7v/gRm7/6u7/827/++78A HMACPMASBFzABnzACJzACrzADNzADvzAEBAcwRI8wRRcwRZ8wRicwRoRvMEc3MEe/MEgHMIiPMIk XMISJnzCKJzCKrzCLNzCLvzCMhMQADs= ------=_NextPart_000_0063_01C10574.6C46A980-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 16:52:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27249 for ; Thu, 5 Jul 2001 16:52:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80186; Thu, 5 Jul 2001 13:55:48 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA79935 for ; Thu, 5 Jul 2001 13:22:59 -0700 (PDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65KHgw13733 for ; Thu, 5 Jul 2001 13:17:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 191018266E for ; Thu, 5 Jul 2001 16:19:16 -0400 (EDT) Message-Id: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: isis-wg@juniper.net From: RJ Atkinson In-Reply-To: <15172.42561.62675.380472@alpha-tli.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 16:14:14 -0400 All, Proposed new revised text for Section 7 is below. This does not change the basic conclusion, though it does add some additional text describing the current deployed reality. Specifically the revised text does attempt to discourage the use of any MTU other than 1518, 4470, or 9180/9200. If this change is accepted, the rest of the document is fine with me. Ran rja@inet.org ================================================================= 7. Default MTU The motivation for this draft was support of FDDI frames across the end-to-end Internet without intermediate fragmentation. According to RFC-1188, the IP MTU over FDDI is 4352 bytes, which is roughly 4470 bytes after including standard framing. RFC-1188 notes that the FDDI frame size as specified by ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI implementations are known to have adhered to RFC-1188. Supporting MPLS over Ethernet without fragmentation requires 4 or 8 additional bytes beyond Ethernet MTU. Supporting Ethernet-layer precedence ("IEEE 802.1p") or Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes beyond the normal Ethernet MTU of 1518 bytes. Many, but not all, deployed servers with Gigabit Ethernet support an IP MTU of 9180. Server throughput is generally related closely to the per-packet processing costs, rather than the per-byte processing costs. So many servers have much better throughput with a larger MTU size. Many, but not all, deployed Gigabit Ethernet switch/router products support an Ethernet MTU of 9200 bytes today. An IP MTU of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, considering Ethernet-layer framing overhead, etc. Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over SMDS. RFC-1626 specifies an IP MTU of 9180 for IP over ATM AAL5. Some equipment providers claim significant cost to support the 9180 IP MTU, while other equipment providers claim that there is no significant change in cost to support 9180 versus 4470 as the IP MTU. Some, but not all, deployed very large backbone routers have support for the 9180 IP MTU over Gigabit Ethernet. A majority of currently deployed PPP over SONET interfaces support a default IP MTU of 4470 bytes. This 4470 MTU is believed to be nearly universal in deployed POS links today, though the POS MTU is theoretically configurable. An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet is recommended when the larger MTU value of 9180 is not needed, because use of the widespread POS MTU (i.e. 4470) greatly reduces the chance of intermediate fragmentation across the end-to-end Internet. If an Ethernet MTU larger than 4470 bytes is needed, then an Ethernet MTU of 9200 bytes is recommended. Use of any Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically discouraged in order to avoid increasing MTU entropy. Varying MTU sizes across the end-to-end Internet path can cause packet loss as part of normal operation of Path MTU Discovery or can cause intermediate fragmentation of IPv4 datagrams. Intermediate fragmentation of IPv4 datagrams is widely believed to be very undesirable. Early implementations of Path MTU Discovery did not always work well. At present, there are mixed reports about the quality of deployed PMTU Discovery implementations. ============================================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 16:57:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27347 for ; Thu, 5 Jul 2001 16:57:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA80259; Thu, 5 Jul 2001 14:00:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80241 for ; Thu, 5 Jul 2001 13:59:45 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [161.44.19.100]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65KsSw15027 for ; Thu, 5 Jul 2001 13:54:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-134-148.cisco.com [64.101.134.148]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA19698; Thu, 5 Jul 2001 13:56:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705155549.0226b108@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "mjyang" From: Micah Bartell Subject: Re: [Isis-wg] [Question] About ISIS packet format? Cc: In-Reply-To: <006701c10528$fc776b80$37c2fe81@etri.re.kr> Mime-Version: 1.0 Content-Type: multipart/related; type="text/plain"; boundary="=====================_20003884==_.REL" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 15:56:09 -0500 --=====================_20003884==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed No, that is incorrect. ISIS packets are not enapsulated in IP. /mpb At 17:03 07/05/2001 +0900, mjyang wrote: >Hi all.. > >We are developing IS-IS routing protocol. >We have some question about ISIS. >In ISIS for IP, I want to confirm ISIS packet encapsulation format. >Is the following figure right? > >Awaiting the pleasure of your reply. >Regards, > >M.J.Yang.. >1312f2f.GIF >----------------- >Mijung Yang / ETRI >TEL: +82-42-860-4922 >FAX: +82-42-860-5440 >E-mail: mjyang@etri.re.kr > --=====================_20003884==_.REL Content-Type: image/gif; name="1312f2f.GIF"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <4.3.2.7.2.20010705155549.0226b108@cactus.cisco.com.1> Content-Disposition: inline; filename="1312f2f.GIF" Content-Transfer-Encoding: base64 R0lGODdhvwPPAvcAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88C QAj/AAMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXQoTgNOnUKNKnUq1qtWrWLNqrTpyq9evYMOK tdp1rNmzaM8yXcu2rdu3SwEglFvQ6UC6BO0mxBuR70G9AejK5Qu1ol+Ph+8aBHwYcN3EQiFvhNwY b+W9kn9mhsu5s+fPoDtu5jiaZ2mLpzE6nig1r0DBigPHppiatsnVhjHnfaqxdujfwIMLdzs4qmvZ yGEHHvx6uXLavB/HZn43Ouuuzq0nb759+XbeuIf6WpZYvPB07srtwgY/3mb74fDjy59P3+H7+qLx u9fPv7///wCuFF6AF91HIEMDHqjgggw26KBCBv4XIYATPmjhhRhmqF+CAVYYHIcahijiiCQ26CFx /p1Y4oostrDoInwgdqaiZjO+aOONOOYIXI038fhSjDoGKeSQREoomHamTYWTecgV6eSTUEaZUVpU VmnllVhmqeWWSHKX3Vx1ndfdc+Wdx16TUqap5pohnUZYlxCymZSPctZp55050bkYZ2/iFh11ZHpp 2Ziv6RmToXgmquiit2XnWHroFfqdXogySpqlmGaq6aYnVcrpp6CGKuqHo5Zq6qmo9udpqqy26uqr KK0K66y01mqrfbfmqorrrrxe2uuvwAYrrJfDFmvssaNSxSJhcS7kW4KDIiutsFxWa+212Gar7bZM Tuvtt4feJmutQE4J7rnoCugos4QmB6hz3sHVZ2XrRWpvk++6y2d52kE65rvgpSvwwCJ5Wu7ABxdI 8MIMT8ntwxBHLPHE1jZs8cUYZ6zxxhx37PHHIIcs8sgkl2zyySg4p6zyyiy37PLLMMcs88w012zz zTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+3001BHLfXUVFcxbfXVWGet9dZcd+3112CHLfbY ZJdt9tlop6322my37fbbcMct99x012333XjnrffefCr37fffgAcu+OCEF2744YgnrvjijDfu+OOQ Ry755JRXbvnlmGeu+eacd+4o+eeghy766KSXbvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3 7qX778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUy/gXY+rBWyh1f6GW/fayYX8knLgWPJf44aOf WMJ5YreY+trDS9m4H9FfPX7rU6r9n/F3b9ij+2NMdSJkqPmth1L6Ix/7HjO+vcymN+5jYHP+lEBo VahLAXMUBO9XJPOQz1kghE6/soc+DdqmYBRsT2YWuJsGVgd8KVQYChGoQghd0DjpswwLHci1QSJ5 8FHzktSRwIemvqymTPHTIQHLQsPdtHCIQ5Sf/RDDRBdKaoBQvOKZjjLFHmKqi/QB44bE6EWPkdF6 OTpjGWWmRqS0kYtvXGPR4qgTOi5Jjo+zo0v0mJId4jFyfGyTZwL5x8ARMjdwLCTzuEIjP1axW3tU DyS390FF0qw0KUzYITVFr/4xEINbLIxxRjjK4lgSXZhsYl/kRUNHHmeV8jrl1X5Yw2YRR5XdE1+0 kqhLIfJJloRWo6UTsejLePHPjMBMZpiUyUwHbbKZ0JTJM6NJzZZMs5rYjFU2t1mfa3Lzm/UDpzh/ M8kR+aVPxELS+mYTxT3hS4Lt+tI4W2Qwby7KlQ+x5zzvJEzy2JCV48MnsfK5rxj6k4f7zFg/r0jJ YjZRoHnC5Z56KagSyvN7b8HhCJ/o0AbqM6EncqrnxyCKIJCa9KQoTalKV8rSlrr0pTCNqUxnStOa 2vSmOM2pTnfKIdOe+vSnQA2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnSiHVqlr1qljNqla3ytWu evWrYA2rWMdK1rKa9axoTata18of1ra69a1wjatc50rXutr1rnjNq173yte++vWvgA2sYB0HS9jC GvawiE2sYhfL2MY69rGQjaxkJ0vZylr2sqmYzaxmN8vZznr2s6ANLeRW9dFXgkSkboxgWVL7WMo8 MFAPXOZBxYSeXb7zOuYDUzoFZdoXslaQ/kMTbAfqW6OUdqmu3e1tiRtbgh6HXTrsLW6BG1zovvZ6 c1LtK62r3Pf9trGk/W44S+JKdum2iKrRbps81JjtNne64O2UeKlI3iVe173Lhe94SQLR9rIzP60V 7gkROt3n6Ku77ymggPUrnfnmx7ywPJ+DfhPLvQWLaVDnfK9zTUsmCA/4tBYuor/Ct0yS7hE7EM5w d0j83OMyl8Ly5aJ6T+viF09GXBMWLX9rnN2Q6hh/HYySiX8cyzQOachE/hCP72ijJSc5oiRysjSl /OTIZIjKKkFylUWEZf6aaMub6jJ9JQRmVGk5x0ou863EPNs0q4eZWsNhc3Df/C05uxNFdL7YmaUZ FzvnGUqXaaSSepS/P7Ns0D5pDaHLaWiUYQUoe/YeI5vy3zvb2M9bDi8y77wZFberw7b1l4Eb3aiG mDc1mBYSGT1M6h6Vz8a25FiqW33jUmcUvzKMMJ5prSBN31rDvA3ULjF8LzvPmtfpZfWrzyuf0Rwb kcg7JlCFPTziCud3Y8+O9odnjLFsaztU3v421sIt7mCWO3bkPvfU0q3uqLG73U97N7ybJu95L63e 9k4avvOAfbR983uO/0advwPeM7IQ3HOKXpGnjYk9S/9XgPGiLfcEiFGGHhxHkW42hyOVr/sO+17N 5W61YY1Z1HYs48C+uLrqO1KDqXwmJpe1y18eLmWb+p9F5m1629yWiic41jS3ZohVLOwSG1u67i26 zlk83FsOvcTBhnrQf4TjMJZU2jMkn7rQWW7GrGt95Ttuua2/Tvaym/3saE+72tfO9ra7/e1wj7vc GOdO97rb/e54z7ve9873vvv974APvOAHTxn4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpbGP7ymM+8 5jfP+c57/vOgD73oR0/60pv+9BeoT73qV8/61rv+9bCPvexnT/va2/72uBbPve53z/ve+/73wA++ 8IdP/OIb//jIFk++8pfP/OY7//nQj770p0/96lv/+tgWz772t8/97nv/++APv/jHT/7ym//86BVP v/rXz/72u//98I+//OdP//rb//4V+M+//vfP//77//8AGIACOIAEWIAGF3iACJiACriADNiADviA EBiBEjiBFFiB/6bia0WhYFwnY7kVdhzoWBhIFBrogR8IYhuYgZCVXPgyXNACbfqjRRtHcgS2X5zm W8NWaGhmLtVlg+w0PzlYWCoYcenkbNs2TIphYLYFESNoaUdkhNj1g7kmW0IoXJ1WYwOnUkH4XMwm hUp4c9+BdLpGg1xIW2M4hSLIbcmVhcWFggFWXdESXZfmgsWFhGDYhR3IaW84h09YgmLYgxKXhGt4 hm1IXlCIGlUHbehlgzOyhCi0Qdv1cTsHgjFmXNyGGPY1UBC3gpdogiQYhYF4bUWoWCEoHpUoGpsY RLcFiHZIXaulgwi1iCk4iWzIio1oiB6nc6q4YZzYipGYPpVWa0OSaHPO0mm2uGIviGCheCnCiHMS Voi5sYy6EY2UGGDU9iZO1E7MYSA3GCZ0KINbSEXV6ITfQ3EoR4jmE45rOI4YVo6lnmhY08ZRRLSO x6iNIVQvKbds4ZRi1nFMOZQePKZg+lhC8uiPzhhY73hh9uJBS8dgEJdivZiPMShqDfUvPSZIDvlp E0mQfLhYo2hld1iLGwlgnSiIIEgxJukVj3SSKjlpNLaSLoloKneFLCGTTUGTJSdkbMKOc6eT/GGT 2vR5PrmLPmR6QekrR7Z6PBlnQZKUiFeUxfgiTNl4TslzJRKVTJE3lbpoTljZblsJdFeGfFbJFF05 Z8o3lvfYIdQ3ll0ZlqzHlh55IG4Je04ZlHFJe3VZR0aifjQ5cHfpe3zZTfbXl5QWH2bZlPNBboVx KZUwQk6JeZXelmqCmX3PZmyNuXmRSYt9ZoHeGJLTqJkOJ5ZKUZlt+Y8GB2me2WaVtGgJVxNHJJq3 t5o9AZMwJ0quiXvKAmmM9iOyeZoitJs7kZozyZIntpD39Y3gB5ysqZq3SXXEiYnDREFPlI16WHGU bNeR3baDQIdOmoiL8DRi1SmL2IadBCZyxkRc5Lli3+mFzTmDGrNqdZh3boJrV3dyh4KcdhefZ0mW 7Wmby1ZL9Pma4MkWp6Ya43GZIll71hkX8jlBcMge09ZwL3R0ADp2Pfeeb/iCkOguTVehE2qOvwZr CRR1S5cvVsShtneQRhRCh6meZAag6Ghx6niEiahkkmGfhD/JnwGpRMHGj7UJmC4akQmZket5nR3q ZZt2oi+ZpEq6pNvCmzDnpJzSo1AaoFOqKFJapUaKpYxypVqKmV1qJ1wq+qVjJqb8RKaJEqZm6ohp 6mNrWido2qZPCadp8qZyymB1+iR0eqerqKeAb8anUpKnfjqfgRpkg+okgFqoxomoGKeoaVSajKpw y8llOPQ//pWosBmYlxoiC1eGnOqV+Tl/k1qVsjVyIuZd+zNB14NLB2RKeRh+NupMo1pszlmDHKef 57mhruoil0qbxERJDyVJvDpALRSdkhRxBp7KVjGHbV7HeMnansu6eM2qUM+qeNHabdOaeNWqZ9dq mCeorBQKrSGWTyskoUOqhAVKmeFqHysEeSgKo9aIjZ4koAvqi1oErFQIh8WUUe0qhEB0YPTqeO3K JDx6URZnojOKixj6iy6Ui5mZo8L6Tgp5sIcXsEGqoaJGrhIbohCrsJ92rL1BsRhJsOjJrIeocYKa Its6sSULIxZUlOx4qCd3la0W87LsurLO+q3UarPSirPYqrPWyrOPGrRCO7REW7RGe7RIm7QTSru0 TNu0Tvu0UBu1Uju1VFu1VhV7tVibtVq7tVzbtV77tWAbtmI7tmQUW7Zme7Zom7Zqu7Zs27Zu+7Zw G7cTcju3dFu3dnu3eJu3eru3fNu3fhT7t4AbuII7uIRbuIZ7uIibuIq7uBOM27iO+7iQG7mSO7mU W7mWe7mYEpu5mru5nNu5nvu5oBu6oju6pBRbuqZ7uqibuqq7uqzbuq77urAbuxKyO7u0W7u2e7u4 m7u6u7u827sSvvu7wBu8wju8xFu8xnu8yJu8Esq7vMzbvM77vNAbvdI7vdRbvRLWe73Ym73au73c 273e+73gG74Q4ju+5Fu+5nu+6Ju+6ru+7BLbvu77vvAbv/I7v/Rbv/Z7v/gRm7/6u7/827/++78A HMACPMASBFzABnzACJzACrzADNzADvzAEBAcwRI8wRRcwRZ8wRicwRoRvMEc3MEe/MEgHMIiPMIk XMISJnzCKJzCKrzCLNzCLvzCMhMQADs= --=====================_20003884==_.REL-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 17:07:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27561 for ; Thu, 5 Jul 2001 17:07:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA80388; Thu, 5 Jul 2001 14:10:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA80363 for ; Thu, 5 Jul 2001 14:09:29 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65L4Dw15440 for ; Thu, 5 Jul 2001 14:04:13 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f65L5hq03139; Thu, 5 Jul 2001 14:05:43 -0700 From: Henk Smit Message-Id: <200107052105.f65L5hq03139@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Re: GigE JumboGrams & IS-IS To: rja@inet.org (RJ Atkinson) Cc: isis-wg@juniper.net In-Reply-To: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> from "RJ Atkinson" at Jul 05, 2001 04:14:14 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 5 Jul 2001 14:05:43 -0700 (PDT) Content-Transfer-Encoding: 7bit > > Proposed new revised text for Section 7 is below. This does > not change the basic conclusion, though it does add some additional > text describing the current deployed reality. Just curious, how many ISIS implementations are out there today that send IIHs larger than 1500 bytes over GigE ? Zero ? One ? Two ? More than two ? henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 18:47:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29261 for ; Thu, 5 Jul 2001 18:47:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA80926; Thu, 5 Jul 2001 15:49:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA80914 for ; Thu, 5 Jul 2001 15:48:51 -0700 (PDT) Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65MhXw18733 for ; Thu, 5 Jul 2001 15:43:33 -0700 (PDT) X-JNPR-Received-From: outside Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id PAA13450; Thu, 5 Jul 2001 15:45:22 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15172.60930.37609.415804@alpha-tli.procket.com> To: RJ Atkinson Cc: isis-wg@juniper.net Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> References: <15172.42561.62675.380472@alpha-tli.procket.com> <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 5 Jul 2001 15:45:22 -0700 Content-Transfer-Encoding: 7bit Some comments on Ran's proposal. | 7. Default MTU | | The motivation for this draft was support of FDDI frames | across the end-to-end Internet without intermediate fragmentation. More accurately: the MTU of much of the deployed core of the Internet was (and is) >= 4000 bytes. | According to RFC-1188, the IP MTU over FDDI is 4352 bytes, | which is roughly 4470 bytes after including standard framing. | RFC-1188 notes that the FDDI frame size as specified by | ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI | implementations are known to have adhered to RFC-1188. Very early FDDI implementations used an MTU of 4470 bytes. This was then propagated into early POS implementations. Somewhere in between RFC 1188 dropped the FDDI MTU to 4352. I'm unaware of any implementations that followed suit. | Supporting MPLS over Ethernet without fragmentation | requires 4 or 8 additional bytes beyond Ethernet MTU. More generally: Support for one level of of MPLS label will require 4 bytes of link layer frame above the IP MTU. Similarly two labels will require 8 bytes. | Supporting Ethernet-layer precedence ("IEEE 802.1p") or | Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes | beyond the normal Ethernet MTU of 1518 bytes. I think many people will find "normal Ethernet MTU" and "1518 bytes" confusing. | Many, but not all, deployed servers with Gigabit Ethernet | support an IP MTU of 9180. Server throughput is generally | related closely to the per-packet processing costs, | rather than the per-byte processing costs. So many servers | have much better throughput with a larger MTU size. Many, | but not all, deployed Gigabit Ethernet switch/router products | support an Ethernet MTU of 9200 bytes today. An IP MTU | of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, | considering Ethernet-layer framing overhead, etc. Specifically, that allows for 20 bytes outside of the IP packet. Certain amounts of overhead are necessary: DA (6 bytes) SA (6 bytes) Type (2 bytes) CRC (4 bytes) This would leave 2 bytes for optional additions. Unfortunately, the common options that I can think of are: VLAN tag (4 bytes) MPLS label (4 bytes) MPLS 2 labels (8 bytes) It appears as if an IP MTU of 9180 is still too large. | Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over | SMDS. I believe that the SMDS experiment is conclucded. ;-) | RFC-1626 specifies an IP MTU of 9180 for IP over | ATM AAL5. Some equipment providers claim significant cost | to support the 9180 IP MTU, while other equipment providers | claim that there is no significant change in cost to support | 9180 versus 4470 as the IP MTU. Some, but not all, deployed | very large backbone routers have support for the 9180 IP MTU | over Gigabit Ethernet. | | A majority of currently deployed PPP over SONET interfaces | support a default IP MTU of 4470 bytes. This 4470 MTU is | believed to be nearly universal in deployed POS links today, | though the POS MTU is theoretically configurable. | | An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet | is recommended when the larger MTU value of 9180 is not needed, | because use of the widespread POS MTU (i.e. 4470) greatly reduces | the chance of intermediate fragmentation across the end-to-end | Internet. If an Ethernet MTU larger than 4470 bytes is needed, | then an Ethernet MTU of 9200 bytes is recommended. Use of any | Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically | discouraged in order to avoid increasing MTU entropy. I would add one more line in here: The default IP MTU for Gigabit Ethernet should be 4470 bytes. While I appreciate the additional discussion, we must not appear to be ambiguous. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 5 20:41:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01576 for ; Thu, 5 Jul 2001 20:41:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA81395; Thu, 5 Jul 2001 17:43:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA81383 for ; Thu, 5 Jul 2001 17:42:16 -0700 (PDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f660avw21943 for ; Thu, 5 Jul 2001 17:36:57 -0700 (PDT) X-JNPR-Received-From: outside Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 528828266E for ; Thu, 5 Jul 2001 20:38:45 -0400 (EDT) Message-Id: <5.1.0.14.2.20010705201440.00a09090@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: isis-wg@juniper.net From: RJ Atkinson Subject: Re: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <15172.60930.37609.415804@alpha-tli.procket.com> References: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> <15172.42561.62675.380472@alpha-tli.procket.com> <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 20:34:33 -0400 At 18:45 05/07/01, Tony Li wrote: > | 7. Default MTU > | > | The motivation for this draft was support of FDDI frames > | across the end-to-end Internet without intermediate fragmentation. > > >More accurately: the MTU of much of the deployed core of the Internet was >(and is) >= 4000 bytes. Please take that level of re-write up with the original authors. I didn't want to edit their assertion of motivation that severely. > | According to RFC-1188, the IP MTU over FDDI is 4352 bytes, > | which is roughly 4470 bytes after including standard framing. > | RFC-1188 notes that the FDDI frame size as specified by > | ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI > | implementations are known to have adhered to RFC-1188. > > >Very early FDDI implementations used an MTU of 4470 bytes. This was then >propagated into early POS implementations. Somewhere in between RFC 1188 >dropped the FDDI MTU to 4352. I'm unaware of any implementations that >followed suit. I'd be interested in Dave Katz's inputs since he wrote that RFC and was involved in the earliest implementations. When you say "MTU", do you mean link MTU or IP MTU ? If you mean link MTU, that's consistent with what I've said above. The as-deployed-for-IP link MTU was 4470 not 4500 bytes, according to RFC-1188. > | Supporting MPLS over Ethernet without fragmentation > | requires 4 or 8 additional bytes beyond Ethernet MTU. > >More generally: Support for one level of of MPLS label will require 4 bytes >of link layer frame above the IP MTU. Similarly two labels will require 8 >bytes. No objection. The quoted text came from the original draft. > | Supporting Ethernet-layer precedence ("IEEE 802.1p") or > | Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes > | beyond the normal Ethernet MTU of 1518 bytes. > > >I think many people will find "normal Ethernet MTU" and "1518 bytes" >confusing. A specific edit proposal would be helpful. > | Many, but not all, deployed servers with Gigabit Ethernet > | support an IP MTU of 9180. Server throughput is generally > | related closely to the per-packet processing costs, > | rather than the per-byte processing costs. So many servers > | have much better throughput with a larger MTU size. Many, > | but not all, deployed Gigabit Ethernet switch/router products > | support an Ethernet MTU of 9200 bytes today. An IP MTU > | of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, > | considering Ethernet-layer framing overhead, etc. > > >Specifically, that allows for 20 bytes outside of the IP packet. Certain >amounts of overhead are necessary: > > DA (6 bytes) > SA (6 bytes) > Type (2 bytes) > CRC (4 bytes) > >This would leave 2 bytes for optional additions. Unfortunately, the common >options that I can think of are: > > VLAN tag (4 bytes) > MPLS label (4 bytes) > MPLS 2 labels (8 bytes) > >It appears as if an IP MTU of 9180 is still too large. Actually, you've just constructed a case that 9220 is too small when one or more of those options are present. The 9180 number is actually deployed pretty widely (e.g. in servers, switches, routers), hence is hard to change at this point. ASIDE: If you do the same math, by the way, for IP over IEEE standard Ethernet, you'll discover that IEEE has 2 link MTUs for standard Ethernet (the original one & an IEEE jumbo frame which increases the max Ethernet frame size by 4 bytes -- for a single VLAN tag). > | Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over > | SMDS. > > >I believe that the SMDS experiment is conclucded. ;-) It is relevant in the same manner that FDDI is relevant, to provide historical context. FDDI is basically gone also at this point. I don't even think FDDI chipsets are in active production any longer, for example. (This caused some panic in parts of the US Navy, whose ships have been using FDDI for many years now as their shipboard backbone). > | RFC-1626 specifies an IP MTU of 9180 for IP over > | ATM AAL5. Some equipment providers claim significant cost > | to support the 9180 IP MTU, while other equipment providers > | claim that there is no significant change in cost to support > | 9180 versus 4470 as the IP MTU. Some, but not all, deployed > | very large backbone routers have support for the 9180 IP MTU > | over Gigabit Ethernet. > | > | A majority of currently deployed PPP over SONET interfaces > | support a default IP MTU of 4470 bytes. This 4470 MTU is > | believed to be nearly universal in deployed POS links today, > | though the POS MTU is theoretically configurable. > | > | An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet > | is recommended when the larger MTU value of 9180 is not needed, > | because use of the widespread POS MTU (i.e. 4470) greatly reduces > | the chance of intermediate fragmentation across the end-to-end > | Internet. If an Ethernet MTU larger than 4470 bytes is needed, > | then an Ethernet MTU of 9200 bytes is recommended. Use of any > | Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically > | discouraged in order to avoid increasing MTU entropy. > > >I would add one more line in here: The default IP MTU for Gigabit Ethernet >should be 4470 bytes. >While I appreciate the additional discussion, we must not appear to be >ambiguous. That is OK, we will have a whole draft on IP/GigE elsewhere. :-) How IP is encapsulated over anything is WAY outside the charter of this WG, whereas how IS-IS is carried anywhere is reasonably within charter for this WG. If you feel compelled to put IP in here specifically, it ought to be phrased as it was by the original authors for IS-IS: An MTU of 4470 bytes for IP packets or IS-IS PDUs over Gigabit Ethernet is recommended when the larger MTU of 9180 is not needed. [remaining text roughly as proposed earlier] Cheers, Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 6 06:53:20 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26344 for ; Fri, 6 Jul 2001 06:53:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA83973; Fri, 6 Jul 2001 03:55:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA83958 for ; Fri, 6 Jul 2001 03:54:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f66AnHw33105 for ; Fri, 6 Jul 2001 03:49:17 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25859; Fri, 6 Jul 2001 06:50:23 -0400 (EDT) Message-Id: <200107061050.GAA25859@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 06:50:23 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-03.txt Pages : 6 Date : 05-Jul-01 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 6 10:54:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06080 for ; Fri, 6 Jul 2001 10:53:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84943; Fri, 6 Jul 2001 07:55:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84928 for ; Fri, 6 Jul 2001 07:54:12 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f66Emkw38183 for ; Fri, 6 Jul 2001 07:48:47 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:50 +0100 X-From_: ietf-123-owner@loki.ietf.org Fri Jul 06 13:34:18 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Fri, 06 Jul 2001 13:34:18 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail13.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15IUoL-0006Mk-00; Fri, 06 Jul 2001 13:34:18 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA24160 for ietf-123-outbound.10@ietf.org; Fri, 6 Jul 2001 07:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23656 for ; Fri, 6 Jul 2001 06:50:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25859; Fri, 6 Jul 2001 06:50:23 -0400 (EDT) Message-Id: <200107061050.GAA25859@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 06 Jul 2001 14:54:50.0477 (UTC) FILETIME=[9B77E1D0:01C1062B] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 06:50:23 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-03.txt Pages : 6 Date : 05-Jul-01 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 9 14:35:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25360 for ; Mon, 9 Jul 2001 14:35:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA04536; Mon, 9 Jul 2001 11:38:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA02609 for ; Mon, 9 Jul 2001 03:20:52 -0700 (PDT) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f69AEww90943 for ; Mon, 9 Jul 2001 03:14:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from ns (mjyang.etri.re.kr [129.254.194.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NT69HZZ7; Mon, 9 Jul 2001 19:14:33 +0900 Message-ID: <006e01c10862$d739ef40$37c2fe81@etri.re.kr> From: "Mijung Yang" To: Organization: ETRI MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C108AE.46F6DDC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Isis-wg] [Question] ISIS encapsulation over AAL5 ? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 9 Jul 2001 19:35:15 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C108AE.46F6DDC0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLi4NCkkgaGF2ZSAyIHF1ZXN0aW9uLi4NCg0KRmlyc3QuLg0KSSB3YW50IHRvIGNvbmZp cm0gdGhlIGZvbGxvd2luZyBkYXRhIGZvcm1hdCBpbiBjYXNlIG9mIHVzaW5nIEFBTDUuLg0KDQor LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgTExDIHwgTkxQSUQgfCAgIElTLUlTIFBEVXMo TGVuZ3RoIEluZGljYXRvciB+KSAgICAgICB8IFBBRCB8IENQQ1MtUERVIHRyYWlsZXIgfA0KKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCkxMQyA9IDB4RkUtRkUtMDMNCk5MUElEID0gMHg4 Mw0KDQpJZiBFUy1JUywgTkxQSUQgPSAgMHg4MiBhbmQgRVMtSVMgUERVKExlbmd0aCBJbmRpY2F0 b3IgfikuDQoNCklzIGl0IHJpZ2h0Pw0KDQpTZWNvbmQuLg0KSW4gSW50ZWdyYXRlZCBJUy1JUyhS RkMgMTE5NSksIHdoaWNoIHZhbHVlIGNhbiBiZSBpbmNsdWRlZCBpbiAiUHJvdG9jb2wgU3VwcG9l cnRlZCIgY29kZT8NCldoYXQgaXMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSAiSW50cmFkb21haW4g Um91dGluZyBQcm90b2NvbCBEaXNjcmltaW5hdG9yIiBpbiBJU0lTIFBEVSBoZWFlciANCmFuZCAi UHJvdG9jb2wgU3VwcG9lcnRlZCIgY29kZSBpbiBJbnRlZ3JhdGVkIElTLUlTPw0KDQpBd2FpdGlu ZyB0aGUgcGxlYXN1cmUgb2YgeW91ciByZXBseS4NClJlZ2FyZHMuLg0KDQotLS0tLS0tLS0tLS0t LS0tLQ0KTWlqdW5nIFlhbmcgLyBFVFJJIA0KVEVMOiArODItNDItODYwLTQ5MjIgDQpGQVg6ICs4 Mi00Mi04NjAtNTQ0MCANCkUtbWFpbDogbWp5YW5nQGV0cmkucmUua3IgDQoNCg== ------=_NextPart_000_006B_01C108AE.46F6DDC0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC4u PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBoYXZlIDIgcXVlc3Rpb24uLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkZpcnN0Li48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdhbnQg dG8gY29uZmlybSB0aGUgZm9sbG93aW5nIGRhdGEgZm9ybWF0IGluIGNhc2Ugb2YgdXNpbmcgDQpB QUw1Li48QlI+PEJSPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxCUj58IA0KTExDIHwgTkxQ SUQgfCZuYnNwOyZuYnNwOyBJUy1JUyBQRFVzKExlbmd0aCBJbmRpY2F0b3IgDQp+KSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFBBRCB8IENQQ1MtUERVIHRyYWlsZXIgDQp8 PEJSPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxCUj48QlI+TExDIA0KPSAweEZFLUZFLTAz PEJSPk5MUElEID0gMHg4MzxCUj48QlI+SWYgRVMtSVMsIE5MUElEID0mbmJzcDsgMHg4MiBhbmQg RVMtSVMgDQpQRFUoTGVuZ3RoIEluZGljYXRvciB+KS48QlI+PEJSPklzIGl0IHJpZ2h0PzxCUj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TZWNvbmQuLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPkluIEludGVncmF0ZWQgSVMtSVMoUkZDIDExOTUpLCB3aGljaCB2YWx1 ZSBjYW4gYmUgaW5jbHVkZWQgaW4gDQoiUHJvdG9jb2wgU3VwcG9lcnRlZCIgY29kZT88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5XaGF0IGlzIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg IkludHJhZG9tYWluIFJvdXRpbmcgUHJvdG9jb2wgDQpEaXNjcmltaW5hdG9yIiBpbiBJU0lTIFBE VSBoZWFlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbmQgIlByb3RvY29sIFN1 cHBvZXJ0ZWQiIGNvZGUgaW4gSW50ZWdyYXRlZCANCklTLUlTPzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjxCUj5Bd2FpdGluZyB0aGUgcGxlYXN1cmUgb2YgeW91ciANCnJlcGx5LjxC Uj5SZWdhcmRzLi48QlI+PC9ESVY+PC9GT05UPg0KPERJVj48Rk9OVCBzaXplPTI+LS0tLS0tLS0t LS0tLS0tLS08QlI+TWlqdW5nIFlhbmcgLyBFVFJJIDxCUj5URUw6IA0KKzgyLTQyLTg2MC00OTIy IDxCUj5GQVg6ICs4Mi00Mi04NjAtNTQ0MCA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzpt anlhbmdAZXRyaS5yZS5rciI+bWp5YW5nQGV0cmkucmUua3I8L0E+IA0KPEJSPjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_006B_01C108AE.46F6DDC0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 12 15:19:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09944 for ; Thu, 12 Jul 2001 15:19:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21810; Thu, 12 Jul 2001 12:21:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21798 for ; Thu, 12 Jul 2001 12:20:10 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6CJDhw57464 for ; Thu, 12 Jul 2001 12:13:43 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 73494 invoked from network); 12 Jul 2001 19:15:53 -0000 Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Jul 2001 19:15:53 -0000 From: "Ken Larmer" To: "Isis-Wg@Juniper. Net" Cc: "Ken Larmer" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [Isis-wg] DR election Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 12 Jul 2001 15:17:08 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id MAA21810 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09944 Hi, I have a question pertaining to the DR election process within Int IS-IS. ISO-10589 states the following: Broadcast subnetworks 8.4.1 Enabling of broadcast circuits When the broadcast circuit is enabled on an Intermediate system the IS shall perform the following actions. a) Commence sending IIH PDUs with the LAN ID field set to the concatenation of its own systemID and its locally assigned one octet Local Circuit ID. b) Solicit the End system configuration as described in 8.4.6 c) Start listening for ISO 9542 ESH PDUs and acquire adjacencies as appropriate. Do not run the Designated Intermediate System election process. d) After waiting iSISHelloTimer × 2 seconds, run the Level 1 and or the level 2 designated intermediate system election process depending on the Intermediate system type. LAN designated intermediate systems The IS shall run the Level 1 and/or the Level 2 Designated Intermediate System election process (depending on the Intermediate system type) whenever an IIH PDU is received or transmitted as described in 8.4.4. (For these purposes, the transmission of the system’s own IIH PDU is equivalent to receiving it). If there has been no change to the information on which the election is performed since the last time it was run, the previous result can be assumed. The relevant information is f) the set of Intermediate system adjacency states; g) the set of Intermediate System priorities (including this system’s); and h) the existence (or otherwise) of at least one “Up” End system (not including manual adjacencies) or Intermediate system adjacency on the circuit. I understanding waiting iSISHelloTimer X 2 seconds when a circuit is first enabled, however, what happens when we have a circuit failure, which times out all of our adjacencies and then the circuit comes back. Do we then run the DR election process after we receive our first LAN IIH with an adjacency reference to us in its IS Neighbors field or do we wait the iSISHelloTimer X 2. If we wait iSISHelloTimer x 2, our convergence times may be delayed considerably? Secondly, our iSISHelloTimer may be different from our neighbors, which we may be unaware of because we have yet to receive an IIH from them. I can see the DR changing multiple times given the correct configuration prior to the correct DR being elected. Should there be some check against the LAN ID contained within the IIH prior to running the DR election process? Your comments greatly appreciated! Cheers, Ken Larmer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 12 15:41:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12970 for ; Thu, 12 Jul 2001 15:41:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21929; Thu, 12 Jul 2001 12:44:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21917 for ; Thu, 12 Jul 2001 12:43:08 -0700 (PDT) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6CJaew58534 for ; Thu, 12 Jul 2001 12:36:40 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 61915 invoked from network); 12 Jul 2001 19:38:51 -0000 Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Jul 2001 19:38:51 -0000 From: "Ken Larmer" To: "Isis-Wg@Juniper. Net" Cc: "Ken Larmer" Subject: RE: [Isis-wg] DR election Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 12 Jul 2001 15:40:05 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id MAA21929 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12970 Hi, I believe I have answered my own question? If there is more than one IS on a LAN, there is already a DR. In accordance with ISO-10589, the DR will use the dRISISHelloTimer = 1 second. So, with this considered, we will receive a LAN IIH from the DR advertising an adjacency to us prior to electing a new DR. This is because we send our LAN IIH to the allL1/L2 multicast address, so all ISs on the LAN will receive it at the same time. Consequently, the IS with the shortest ISISHelloTimer will be the first system we form an adjacency with. If we do not have a higher priority than the current DR, than we will not elect ourselves as the DR. Thanks, Ken > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Ken Larmer > Sent: Thursday, July 12, 2001 3:17 PM > To: Isis-Wg@Juniper. Net > Cc: Ken Larmer > Subject: [Isis-wg] DR election > > > Hi, > > I have a question pertaining to the DR election process > within Int IS-IS. > ISO-10589 states the following: > > Broadcast subnetworks > > 8.4.1 Enabling of broadcast circuits > > When the broadcast circuit is enabled on an Intermediate system > the IS shall > perform the following actions. > > a) Commence sending IIH PDUs with the LAN ID field set to the > concatenation > of its own systemID and its locally assigned one octet Local Circuit ID. > > b) Solicit the End system configuration as described in 8.4.6 > > c) Start listening for ISO 9542 ESH PDUs and acquire adjacencies as > appropriate. Do not run the Designated Intermediate System > election process. > > d) After waiting iSISHelloTimer × 2 seconds, run the Level 1 and or the > level 2 designated intermediate system election process depending on the > Intermediate system type. > > > LAN designated intermediate systems > > The IS shall run the Level 1 and/or the Level 2 Designated Intermediate > System election process (depending on the Intermediate system > type) whenever > an IIH PDU is received or transmitted as described in 8.4.4. (For these > purposes, the transmission of the system’s own IIH PDU is equivalent to > receiving it). If there has been no change to the information on which the > election is performed since the last time it was run, the previous result > can be assumed. The relevant information is > > f) the set of Intermediate system adjacency states; > > g) the set of Intermediate System priorities (including this > system’s); and > > h) the existence (or otherwise) of at least one “Up” End system (not > including manual adjacencies) or Intermediate system adjacency on the > circuit. > > > I understanding waiting iSISHelloTimer X 2 seconds when a > circuit is first > enabled, however, what happens when we have a circuit failure, which times > out all of our adjacencies and then the circuit comes back. Do we then run > the DR election process after we receive our first LAN IIH with > an adjacency > reference to us in its IS Neighbors field or do we wait the > iSISHelloTimer X > 2. If we wait iSISHelloTimer x 2, our convergence times may be delayed > considerably? > > Secondly, our iSISHelloTimer may be different from our > neighbors, which we > may be unaware of because we have yet to receive an IIH from > them. I can see > the DR changing multiple times given the correct configuration > prior to the > correct DR being elected. Should there be some check against the LAN ID > contained within the IIH prior to running the DR election process? > > Your comments greatly appreciated! > > Cheers, > Ken Larmer > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 13 14:35:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20191 for ; Fri, 13 Jul 2001 14:35:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA27575; Fri, 13 Jul 2001 11:38:15 -0700 (PDT) Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA27563 for ; Fri, 13 Jul 2001 11:37:27 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id LAA20403; Fri, 13 Jul 2001 11:33:04 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15183.16096.534542.645079@alpha-tli.procket.com> To: isis-wg@spider.juniper.net X-Mailer: VM 6.92 under Emacs 20.5.1 Subject: [Isis-wg] London Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 13 Jul 2001 11:33:04 -0700 Content-Transfer-Encoding: 7bit Folks, There are currently no plans to have a WG meeting in London. We'd like to encourage people to continue to contribute via the mailing list. Thanks, Tony & Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 16 07:07:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11924 for ; Mon, 16 Jul 2001 07:07:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA44528; Mon, 16 Jul 2001 04:07:44 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA44513 for ; Mon, 16 Jul 2001 04:05:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6GAwow44996 for ; Mon, 16 Jul 2001 03:58:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10237; Mon, 16 Jul 2001 07:00:17 -0400 (EDT) Message-Id: <200107161100.HAA10237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ospf@discuss.microsoft.com, isis-wg@juniper.net, tewg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ash-ospf-isis-congestion-control-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 07:00:17 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks Author(s) : J. Ash Filename : draft-ash-ospf-isis-congestion-control-00.txt Pages : Date : 13-Jul-01 Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-ospf-isis-congestion-control-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010713124200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-ospf-isis-congestion-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124200.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 16 19:11:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00727 for ; Mon, 16 Jul 2001 19:11:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA47422; Mon, 16 Jul 2001 16:14:15 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA47410 for ; Mon, 16 Jul 2001 16:13:15 -0700 (PDT) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id A6170477902; Mon, 16 Jul 2001 16:08:28 -0700 (PDT) Message-ID: <3B536FB3.18D25B55@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] London References: <15183.16096.534542.645079@alpha-tli.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 15:50:27 -0700 Content-Transfer-Encoding: 7bit Tony Li wrote: > Folks, > > There are currently no plans to have a WG meeting in London. We'd like to > encourage people to continue to contribute via the mailing list. that was crying wolf a little to early. I will be in London Wed-Sat and requested a slot since there are enough things in flux to talk about IMHO ... If I get a slot I'll send a call for agenda items ... thanks --- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 16 19:59:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10311 for ; Mon, 16 Jul 2001 19:59:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA47693; Mon, 16 Jul 2001 17:02:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA14690 for ; Wed, 11 Jul 2001 05:49:48 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6BChVw89211 for ; Wed, 11 Jul 2001 05:43:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA13673 for "workgroup"; Wed, 11 Jul 2001 17:44:25 +0530 From: "Sivakumar A" Message-Id: <200107111214.RAA13673@WS0005.indiatimes.com> To: "workgroup" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151" MIME-Version: 1.0 Subject: [Isis-wg] Partion Repair in IP Router Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 17:57:20 +0530 --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151 Content-Type: text/plain; charset=us-ascii Hello all, Is Partition Detection and Repair supported for IP only routers? Thanks in Advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151 Content-Type: text/html; charset=us-ascii

Hello all,

Is Partition Detection and Repair supported for IP only routers?

Thanks in Advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 16 20:01:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10601 for ; Mon, 16 Jul 2001 20:00:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA47715; Mon, 16 Jul 2001 17:04:01 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA26306 for ; Fri, 13 Jul 2001 06:22:17 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6DDFew86119 for ; Fri, 13 Jul 2001 06:15:41 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id SAA21319 for "workgroup"; Fri, 13 Jul 2001 18:16:08 +0530 From: "Sivakumar A" Message-Id: <200107131246.SAA21319@WS0005.indiatimes.com> To: "workgroup" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878" MIME-Version: 1.0 Subject: [Isis-wg] Partition repair for IP ONLY routers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 13 Jul 2001 18:23:37 +0530 --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878 Content-Type: text/plain; charset=us-ascii Hello all, Is Partition Detection and Repair supported for IP only routers? Thanks in Advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878 Content-Type: text/html; charset=us-ascii

Hello all,

Is Partition Detection and Repair supported for IP only routers?

Thanks in Advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 16 21:01:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23712 for ; Mon, 16 Jul 2001 21:01:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA48058; Mon, 16 Jul 2001 18:02:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA48046 for ; Mon, 16 Jul 2001 18:01:42 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6H0sWw77184 for ; Mon, 16 Jul 2001 17:54:32 -0700 (PDT) X-JNPR-Received-From: outside Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6H0v5V15989; Mon, 16 Jul 2001 17:57:05 -0700 (PDT) Received: from cisco.com (irp-view7.cisco.com [171.69.25.24]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAW09899 (AUTH sluong); Mon, 16 Jul 2001 17:56:54 -0700 (PDT) Message-ID: <3B538D55.D804614F@cisco.com> From: Steven Luong X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tony Przygienda , chopps@nexthop.com CC: sluong@cisco.com, isis-wg@juniper.net References: <200102281155.GAA02125@ietf.org> <20010228112859.C27593@ivmg.net> <3A9DDE62.5F271B14@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 17:56:53 -0700 Content-Transfer-Encoding: 7bit I saw MT-ID 2 is reserved for IPv6 routing topology. There is no Multi-Topology Reachable IPv6 Prefixes TLV defined. So I assume that the only way to advertise IPv6 Reachability Prefixes is via 236, defined in draft-ietf-isis-ipv6-02.txt. If somebody is to implement ISIS-IPv6 multi-topology, how do these two drafts fit together? Do you advertise IS adjacencies via MT Intermediate Systems TLV and Reachability Prefixes via 236? People who implemented ISIS-IPv6 using draft-ietf-isis-ipv6-02.txt may not understand MT Intermediate Systems TLV and they expect either IS Reachability TLV or Extended IS Reachability TLV only. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 08:33:20 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23732 for ; Tue, 17 Jul 2001 08:33:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA50918; Tue, 17 Jul 2001 05:35:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA50903 for ; Tue, 17 Jul 2001 05:34:11 -0700 (PDT) Received: from smtp.huawei.com (sz135.szptt.net.cn [202.96.135.132] (may be forged)) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HCIZw90298 for ; Tue, 17 Jul 2001 05:18:36 -0700 (PDT) X-JNPR-Received-From: outside Received: from rajeshh ([10.110.8.198]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GGM9Z902.E2Q for ; Tue, 17 Jul 2001 20:13:57 +0800 Message-ID: <010001c10f38$e5a89360$c6086e0a@rajeshh> Reply-To: "Rajesh Hegde" From: "Rajesh Hegde" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01C10EFE.391760C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Isis-wg] Isis-wg] - Regarding IS-IS LSP mtu size Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 20:22:38 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_00FD_01C10EFE.391760C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Following are the doubts regarding the usage of size of LSP mtu By having default size of 1497 bytes works for most of the data link = types. Ex : Ethernet, FrameRelay and Serial Links where the size of the = DataLink BlockSize is 1500 bytes. =20 1 ) How it should be handled If the datalink type is POS where the = default DataLinkBlockSize is 512 bytes ? 2) How the negotiation of the Hello PDUs to be done in case of FDDI and = Gigabit ethernet where the DataLinkBlockSize is greater than the default = size of 1497 bytes ? (i.e Do we pad the Hello PDU to the size of DataLink Block Size or = increase the LSP MTU size ? )=20 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp = mtu and level 2 lsp-mtu) be made configurable ? Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 = Gigabit ethernet (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 = bytes ) In this case how to decide the size of the LSP-mtu ? Thanks and Regards, Rajesh ------=_NextPart_000_00FD_01C10EFE.391760C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Following are the doubts regarding = the usage=20 of size of LSP mtu
 
By having default size of 1497 bytes = works for most=20 of the data link types. Ex : Ethernet, FrameRelay and Serial Links where = the=20 size of the DataLink BlockSize is 1500 bytes.
 
1 )  How it should be handled If = the datalink=20 type is POS where the default DataLinkBlockSize is     = 512 bytes=20 ?
 
2) How the negotiation of the Hello = PDUs to be done=20 in case of FDDI and Gigabit ethernet where the DataLinkBlockSize is = greater than=20 the default size of 1497 bytes ?
(i.e Do we pad the Hello PDU to the = size of=20 DataLink Block Size or increase the LSP MTU size ? ) 
 
3) Shall the=20 parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and = level 2=20 lsp-mtu) be made configurable ?
 
Suppose a router with 3 interfaces 1 = ethernet(Link=20 Mtu 1500 bytes), 1 Gigabit ethernet (Link MTU is 9180 bytes), 1 POS = interface (link MTU 512 bytes )
 
In this case how to decide the size of = the LSP-mtu=20 ?
 
Thanks and Regards,
Rajesh
 
 
 
 
------=_NextPart_000_00FD_01C10EFE.391760C0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 13:39:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29477 for ; Tue, 17 Jul 2001 13:39:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA52220; Tue, 17 Jul 2001 10:43:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA52205 for ; Tue, 17 Jul 2001 10:42:56 -0700 (PDT) Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HHZdw03289 for ; Tue, 17 Jul 2001 10:35:39 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.49.102]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGM00133OZFUE@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Tue, 17 Jul 2001 10:38:04 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3B5473C2.C81EBCFA@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 Subject: [Isis-wg] FYI: small draft with TLV numbers ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 10:20:03 -0700 Content-Transfer-Encoding: 7BIT Put a small draft together to prevent TLV conflicts, would appreciate if the word spreads to SIF and OSI so we have a place people can check before steping on each others' toes. If missed something or inexact, pls let me know and will correct and put updated version out ... thansk - tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Redback July 2001 Reserved TLV Codepoints in ISIS Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. Przygienda Expires Jan 2002 [Page 1] Internet Draft TLV Codepoints July 2001 1. TLV Codepoints reserved ___________________________________________________________ Name Value IIH LSP SNP Status ___________________________________________________________ Area Addresses 1 y y n RFC IIS Neighbors 2 n y n RFC ES Neighbors 3 n y n RFC Part. DIS 4 n y n RFC Prefix Neighbors 5 n y n RFC IIS Neighbors 6 y n n RFC Padding 8 y n n RFC LSP Entries 9 n n y RFC Authentication 10 y y y IETF-draft Opt. Checksum 12 y n y IETF-draft LSPBufferSize 14 y? y n SIF-draft TE IIS Neigh. 22 n y n IETF-draft MT-ISN 222 n y n IETF-draft IP Int. Reach 128 n y n RFC Prot. Supported 129 y y n RFC M-Topologies 229 y y n IETF-draft IP Ext. Address 130 n y n RFC IDRPI 131 n y y RFC IP Intf. Address 132 y y n RFC IPv6 Intf. Addr. 232 y y n IETF-draft illegal 133 n n n ? Router ID 134 n y n IETF-draft TE IP. Reach 135 n y n IETF-draft MT IP. Reach 235 n y n IETF-draft IPv6 IP. Reach 236 n y n IETF-draft Dynamic Name 137 n y n RFC 3-Way hellos 240 y n n RFC 2. Assignment Procedures This document is provided to avoid possible future conflicts in assignment of TLV numbers. It does not constitute or represent any standard or authority assigning TLV numbers. TLV assignment happens on a shared, informational basis between the ISO, SIF and the IETF working groups. The core ISIS protocol is being specified in the ISO standards body, IP extensions to it however are products of the ISIS working group in IETF. Since ISO does not provide a numbering authority and IANA is only responsible for IP related coding points, Przygienda Expires Jan 2002 [Page 2] Internet Draft TLV Codepoints July 2001 no plausible central authority to assign TLV numbers exists as of today. 3. Acknowledgments 4. Security Consideration ISIS security applies to the work presented. No specific security issues are being introduced. References [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. INTERNET-RFC, Internet Engineering Task Force, February 1990. [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. 5. Authors' Addresses Tony Przygienda Redback Networks 350 Holger Way San Jose, CA, 95134-1362 prz@redback.com 6. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, Przygienda Expires Jan 2002 [Page 3] Internet Draft TLV Codepoints July 2001 this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Przygienda Expires Jan 2002 [Page 4] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 14:10:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07476 for ; Tue, 17 Jul 2001 14:10:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52431; Tue, 17 Jul 2001 11:14:15 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA52200 for ; Tue, 17 Jul 2001 10:41:32 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HHYEw03225 for ; Tue, 17 Jul 2001 10:34:14 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: [Isis-wg] Note Well Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 13:16:53 -0400 Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 14:22:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09527 for ; Tue, 17 Jul 2001 14:22:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52538; Tue, 17 Jul 2001 11:27:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52526 for ; Tue, 17 Jul 2001 11:26:25 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HIJ7w05612 for ; Tue, 17 Jul 2001 11:19:07 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com ([10.49.188.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA27122; Tue, 17 Jul 2001 19:21:27 +0100 (BST) Message-Id: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: mike shand Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... Cc: isis-wg@juniper.net In-Reply-To: <3B5473C2.C81EBCFA@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 19:21:21 +0100 You missed 42. DECnet PhaseIV :-) But this is a VERY good idea. Thanks. Mike At 10:20 17/07/2001 -0700, Tony Przygienda wrote: >Put a small draft together to prevent TLV conflicts, would appreciate if >the word spreads >to SIF and OSI so we have a place people can check before steping on >each others' toes. >If missed something or inexact, pls let me know and will correct and put >updated version >out ... > > thansk > > - tony > > > > >Internet Engineering Task Force T. >Przygienda >INTERNET DRAFT >Redback > >July 2001 > Reserved TLV Codepoints in ISIS > > > > >Status of This Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet-Drafts are >working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six >months > and may be updated, replaced, or obsoleted by other documents at > any time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice Copyright (C) The Internet Society (2000). All > Rights Reserved. > > > >Abstract > > This draft describes implementation codepoints within > IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for > routing within their clouds. IS-IS is an interior gateway routing > protocol developed originally by OSI and used with IP extensions as > IGP. This draft summarizes all TLV codepoints that are being used by > > the protocol and its pending extensions. > > >Przygienda Expires Jan 2002 >[Page 1] > >Internet Draft TLV Codepoints >July 2001 > >1. TLV Codepoints reserved > ___________________________________________________________ > Name Value IIH LSP SNP Status > > ___________________________________________________________ > > Area Addresses 1 y y n RFC > IIS Neighbors 2 n y n RFC > ES Neighbors 3 n y n RFC > Part. DIS 4 n y n RFC > Prefix Neighbors 5 n y n RFC > IIS Neighbors 6 y n n RFC > Padding 8 y n n RFC > LSP Entries 9 n n y RFC > Authentication 10 y y y IETF-draft > Opt. Checksum 12 y n y IETF-draft > LSPBufferSize 14 y? y n SIF-draft > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > IP Int. Reach 128 n y n RFC > Prot. Supported 129 y y n RFC > M-Topologies 229 y y n IETF-draft > IP Ext. Address 130 n y n RFC > IDRPI 131 n y y RFC > IP Intf. Address 132 y y n RFC > IPv6 Intf. Addr. 232 y y n IETF-draft > illegal 133 n n n ? > Router ID 134 n y n IETF-draft > TE IP. Reach 135 n y n IETF-draft > MT IP. Reach 235 n y n IETF-draft > IPv6 IP. Reach 236 n y n IETF-draft > Dynamic Name 137 n y n RFC > 3-Way hellos 240 y n n RFC > > > >2. Assignment Procedures > > This document is provided to avoid possible future conflicts in > assignment of TLV numbers. It does not constitute or represent any > standard or authority assigning TLV numbers. TLV assignment happens > > on a shared, informational basis between the ISO, SIF and the IETF > working groups. The core ISIS protocol is being specified in the > ISO standards body, IP extensions to it however are products of the > ISIS working group in IETF. Since ISO does not provide a numbering > authority and IANA is only responsible for IP related coding points, > > > >Przygienda Expires Jan 2002 >[Page 2] > >Internet Draft TLV Codepoints >July 2001 > > no plausible central authority to assign TLV numbers exists as of > today. > > > >3. Acknowledgments > >4. Security Consideration > > ISIS security applies to the work presented. No specific security > issues are being introduced. >References > > [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. > INTERNET-RFC, Internet Engineering Task Force, February > 1990. > > > [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual > > Environments. INTERNET-RFC, Internet Engineering Task > Force, December 1990. > > > [ISO90] ISO. Information Technology - Telecommunications and > Information Exchange between Systems - Intermediate System > > to Intermediate System Routing Exchange Protocol for > Use in Conjunction with the Protocol for Providing the > Connectionless-Mode Network Service. ISO, 1990. > > > >5. Authors' Addresses > > Tony Przygienda > Redback Networks > 350 Holger Way > San Jose, CA, 95134-1362 > prz@redback.com > > > >6. Full Copyright Statement > > Copyright (C) The Internet Society (1997). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, >Przygienda Expires Jan 2002 >[Page 3] > >Internet Draft TLV Codepoints >July 2001 > > this document itself may not be modified in any way, such as by > removing the copyright notice or references to the Internet Society > or other Internet organizations, except as needed for the purpose > of developing Internet standards in which case the procedures > for copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > >Przygienda Expires Jan 2002 >[Page 4] > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 14:53:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15736 for ; Tue, 17 Jul 2001 14:53:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52787; Tue, 17 Jul 2001 11:58:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52775 for ; Tue, 17 Jul 2001 11:57:11 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HInqw07316 for ; Tue, 17 Jul 2001 11:49:53 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-134-151.cisco.com [64.101.134.151]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10192; Tue, 17 Jul 2001 11:52:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20010717135115.03269e98@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Learman From: Micah Bartell Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... Cc: Tony Przygienda , isis-wg@juniper.net In-Reply-To: <4.3.2.7.2.20010717143108.0208ed58@dingdong.cisco.com> References: <3B5473C2.C81EBCFA@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 13:52:15 -0500 Just replacing SIF w/ ISO should be sufficient. Along with the other TLV's marked RFC that are actually ISO defined. /mpb At 14:39 07/17/2001 -0400, Jeff Learman wrote: >FYI, > >SIF, the SONET Interoperability Forum, rechartered themselves as >NSIF, the Network and Services Integration Forum. (For more info, >see "http://www.atis.org/atis/sif/sifhom.htm".) > >SIF did not allocate TLV IDs; rather, member company contributors >directed their requests through their ISO member organizations. >There should be no need to mention SIF in this document. > >Regards, >Jeff > >At 01:20 PM 7/17/2001, Tony Przygienda wrote: > >Put a small draft together to prevent TLV conflicts, would appreciate if > >the word spreads > >to SIF and OSI so we have a place people can check before steping on > >each others' toes. > >If missed something or inexact, pls let me know and will correct and put > >updated version > >out ... > > > > thansk > > > > - tony > > > > > > > > > >Internet Engineering Task Force T. > >Przygienda > >INTERNET DRAFT > >Redback > > > >July 2001 > > Reserved TLV Codepoints in ISIS > > > > > > > > > >Status of This Memo > > > > This document is an Internet-Draft and is in full conformance with > > all provisions of Section 10 of RFC2026. Internet-Drafts are > >working > > documents of the Internet Engineering Task Force (IETF), its areas, > > and its working groups. Note that other groups may also distribute > > working documents as Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > >months > > and may be updated, replaced, or obsoleted by other documents at > > any time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > Copyright Notice Copyright (C) The Internet Society (2000). All > > Rights Reserved. > > > > > > > >Abstract > > > > This draft describes implementation codepoints within > > IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for > > routing within their clouds. IS-IS is an interior gateway routing > > protocol developed originally by OSI and used with IP extensions as > > IGP. This draft summarizes all TLV codepoints that are being used by > > > > the protocol and its pending extensions. > > > > > >Przygienda Expires Jan 2002 > >[Page 1] > > > >Internet Draft TLV Codepoints > >July 2001 > > > >1. TLV Codepoints reserved > > ___________________________________________________________ > > Name Value IIH LSP SNP Status > > > > ___________________________________________________________ > > > > Area Addresses 1 y y n RFC > > IIS Neighbors 2 n y n RFC > > ES Neighbors 3 n y n RFC > > Part. DIS 4 n y n RFC > > Prefix Neighbors 5 n y n RFC > > IIS Neighbors 6 y n n RFC > > Padding 8 y n n RFC > > LSP Entries 9 n n y RFC > > Authentication 10 y y y IETF-draft > > Opt. Checksum 12 y n y IETF-draft > > LSPBufferSize 14 y? y n SIF-draft > > TE IIS Neigh. 22 n y n IETF-draft > > MT-ISN 222 n y n IETF-draft > > IP Int. Reach 128 n y n RFC > > Prot. Supported 129 y y n RFC > > M-Topologies 229 y y n IETF-draft > > IP Ext. Address 130 n y n RFC > > IDRPI 131 n y y RFC > > IP Intf. Address 132 y y n RFC > > IPv6 Intf. Addr. 232 y y n IETF-draft > > illegal 133 n n n ? > > Router ID 134 n y n IETF-draft > > TE IP. Reach 135 n y n IETF-draft > > MT IP. Reach 235 n y n IETF-draft > > IPv6 IP. Reach 236 n y n IETF-draft > > Dynamic Name 137 n y n RFC > > 3-Way hellos 240 y n n RFC > > > > > > > >2. Assignment Procedures > > > > This document is provided to avoid possible future conflicts in > > assignment of TLV numbers. It does not constitute or represent any > > standard or authority assigning TLV numbers. TLV assignment happens > > > > on a shared, informational basis between the ISO, SIF and the IETF > > working groups. The core ISIS protocol is being specified in the > > ISO standards body, IP extensions to it however are products of the > > ISIS working group in IETF. Since ISO does not provide a numbering > > authority and IANA is only responsible for IP related coding points, > > > > > > > >Przygienda Expires Jan 2002 > >[Page 2] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > no plausible central authority to assign TLV numbers exists as of > > today. > > > > > > > >3. Acknowledgments > > > >4. Security Consideration > > > > ISIS security applies to the work presented. No specific security > > issues are being introduced. > >References > > > > [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. > > INTERNET-RFC, Internet Engineering Task Force, February > > 1990. > > > > > > [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual > > > > Environments. INTERNET-RFC, Internet Engineering Task > > Force, December 1990. > > > > > > [ISO90] ISO. Information Technology - Telecommunications and > > Information Exchange between Systems - Intermediate System > > > > to Intermediate System Routing Exchange Protocol for > > Use in Conjunction with the Protocol for Providing the > > Connectionless-Mode Network Service. ISO, 1990. > > > > > > > >5. Authors' Addresses > > > > Tony Przygienda > > Redback Networks > > 350 Holger Way > > San Jose, CA, 95134-1362 > > prz@redback.com > > > > > > > >6. Full Copyright Statement > > > > Copyright (C) The Internet Society (1997). All Rights Reserved. > > > > This document and translations of it may be copied and furnished to > > others, and derivative works that comment on or otherwise explain it > > > > or assist in its implementation may be prepared, copied, published > > and distributed, in whole or in part, without restriction of any > > kind, provided that the above copyright notice and this paragraph > > are included on all such copies and derivative works. However, > >Przygienda Expires Jan 2002 > >[Page 3] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > this document itself may not be modified in any way, such as by > > removing the copyright notice or references to the Internet Society > > or other Internet organizations, except as needed for the purpose > > of developing Internet standards in which case the procedures > > for copyrights defined in the Internet Standards process must be > > followed, or as required to translate it into languages other than > > English. > > > > The limited permissions granted above are perpetual and will not be > > revoked by the Internet Society or its successors or assigns. > > > > This document and the information contained herein is provided on an > > > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > > >Przygienda Expires Jan 2002 > >[Page 4] > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 15:10:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19505 for ; Tue, 17 Jul 2001 15:10:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52689; Tue, 17 Jul 2001 11:48:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA52677 for ; Tue, 17 Jul 2001 11:47:31 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HIeDw06730 for ; Tue, 17 Jul 2001 11:40:13 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6HIgbv04855; Tue, 17 Jul 2001 14:42:37 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-111.cisco.com [64.102.83.111]) by dingdong.cisco.com (Mirapoint) with ESMTP id AEQ02506; Tue, 17 Jul 2001 14:42:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717143108.0208ed58@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: Jeff Learman Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... Cc: isis-wg@juniper.net In-Reply-To: <3B5473C2.C81EBCFA@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 14:39:36 -0400 FYI, SIF, the SONET Interoperability Forum, rechartered themselves as NSIF, the Network and Services Integration Forum. (For more info, see "http://www.atis.org/atis/sif/sifhom.htm".) SIF did not allocate TLV IDs; rather, member company contributors directed their requests through their ISO member organizations. There should be no need to mention SIF in this document. Regards, Jeff At 01:20 PM 7/17/2001, Tony Przygienda wrote: >Put a small draft together to prevent TLV conflicts, would appreciate if >the word spreads >to SIF and OSI so we have a place people can check before steping on >each others' toes. >If missed something or inexact, pls let me know and will correct and put >updated version >out ... > > thansk > > - tony > > > > >Internet Engineering Task Force T. >Przygienda >INTERNET DRAFT >Redback > >July 2001 > Reserved TLV Codepoints in ISIS > > > > >Status of This Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet-Drafts are >working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six >months > and may be updated, replaced, or obsoleted by other documents at > any time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice Copyright (C) The Internet Society (2000). All > Rights Reserved. > > > >Abstract > > This draft describes implementation codepoints within > IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for > routing within their clouds. IS-IS is an interior gateway routing > protocol developed originally by OSI and used with IP extensions as > IGP. This draft summarizes all TLV codepoints that are being used by > > the protocol and its pending extensions. > > >Przygienda Expires Jan 2002 >[Page 1] > >Internet Draft TLV Codepoints >July 2001 > >1. TLV Codepoints reserved > ___________________________________________________________ > Name Value IIH LSP SNP Status > > ___________________________________________________________ > > Area Addresses 1 y y n RFC > IIS Neighbors 2 n y n RFC > ES Neighbors 3 n y n RFC > Part. DIS 4 n y n RFC > Prefix Neighbors 5 n y n RFC > IIS Neighbors 6 y n n RFC > Padding 8 y n n RFC > LSP Entries 9 n n y RFC > Authentication 10 y y y IETF-draft > Opt. Checksum 12 y n y IETF-draft > LSPBufferSize 14 y? y n SIF-draft > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > IP Int. Reach 128 n y n RFC > Prot. Supported 129 y y n RFC > M-Topologies 229 y y n IETF-draft > IP Ext. Address 130 n y n RFC > IDRPI 131 n y y RFC > IP Intf. Address 132 y y n RFC > IPv6 Intf. Addr. 232 y y n IETF-draft > illegal 133 n n n ? > Router ID 134 n y n IETF-draft > TE IP. Reach 135 n y n IETF-draft > MT IP. Reach 235 n y n IETF-draft > IPv6 IP. Reach 236 n y n IETF-draft > Dynamic Name 137 n y n RFC > 3-Way hellos 240 y n n RFC > > > >2. Assignment Procedures > > This document is provided to avoid possible future conflicts in > assignment of TLV numbers. It does not constitute or represent any > standard or authority assigning TLV numbers. TLV assignment happens > > on a shared, informational basis between the ISO, SIF and the IETF > working groups. The core ISIS protocol is being specified in the > ISO standards body, IP extensions to it however are products of the > ISIS working group in IETF. Since ISO does not provide a numbering > authority and IANA is only responsible for IP related coding points, > > > >Przygienda Expires Jan 2002 >[Page 2] > >Internet Draft TLV Codepoints >July 2001 > > no plausible central authority to assign TLV numbers exists as of > today. > > > >3. Acknowledgments > >4. Security Consideration > > ISIS security applies to the work presented. No specific security > issues are being introduced. >References > > [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. > INTERNET-RFC, Internet Engineering Task Force, February > 1990. > > > [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual > > Environments. INTERNET-RFC, Internet Engineering Task > Force, December 1990. > > > [ISO90] ISO. Information Technology - Telecommunications and > Information Exchange between Systems - Intermediate System > > to Intermediate System Routing Exchange Protocol for > Use in Conjunction with the Protocol for Providing the > Connectionless-Mode Network Service. ISO, 1990. > > > >5. Authors' Addresses > > Tony Przygienda > Redback Networks > 350 Holger Way > San Jose, CA, 95134-1362 > prz@redback.com > > > >6. Full Copyright Statement > > Copyright (C) The Internet Society (1997). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, >Przygienda Expires Jan 2002 >[Page 3] > >Internet Draft TLV Codepoints >July 2001 > > this document itself may not be modified in any way, such as by > removing the copyright notice or references to the Internet Society > or other Internet organizations, except as needed for the purpose > of developing Internet standards in which case the procedures > for copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > >Przygienda Expires Jan 2002 >[Page 4] > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 17 18:30:34 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28742 for ; Tue, 17 Jul 2001 18:30:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA53777; Tue, 17 Jul 2001 15:35:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA53762 for ; Tue, 17 Jul 2001 15:34:14 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6HMQsw18176 for ; Tue, 17 Jul 2001 15:26:54 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id B48921DCC70; Tue, 17 Jul 2001 15:29:20 -0700 (PDT) Message-ID: <3B54B807.EFACCE18@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: mike shand Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... References: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 15:11:19 -0700 Content-Transfer-Encoding: 7bit mike shand wrote: > You missed 42. DECnet PhaseIV :-) > > But this is a VERY good idea. Thanks. > > will do, don't want to get into trouble with anyone out there still running it. Do we put DEC or Compaq as the authority that assigned that number ;-)) ? ---- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 07:00:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26301 for ; Wed, 18 Jul 2001 07:00:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA56912; Wed, 18 Jul 2001 04:05:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA56897 for ; Wed, 18 Jul 2001 04:04:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6IAvXw34255 for ; Wed, 18 Jul 2001 03:57:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24946; Wed, 18 Jul 2001 06:57:57 -0400 (EDT) Message-Id: <200107181057.GAA24946@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 06:57:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-01.txt Pages : 6 Date : 17-Jul-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-transient-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-transient-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717132951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132951.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 13:57:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23257 for ; Wed, 18 Jul 2001 13:57:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA58566; Wed, 18 Jul 2001 11:02:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA58554 for ; Wed, 18 Jul 2001 11:01:20 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6IHrpw50063 for ; Wed, 18 Jul 2001 10:53:52 -0700 (PDT) X-JNPR-Received-From: outside Received: from nut.tcb.net (danny@localhost) by tcb.net (8.11.4/8.11.4) with ESMTP id f6IHw1i22475 for ; Wed, 18 Jul 2001 11:58:01 -0600 Message-Id: <200107181758.f6IHw1i22475@tcb.net> X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 11:58:01 -0600 Folks, the only update in this version is the addition of some text surrounding handling of "stale" LSPs. Thanks to Stefano for pointing this out. -danny > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. > > Title : IS-IS Transient Blackhole Avoidance > Author(s) : D. McPherson > Filename : draft-ietf-isis-transient-01.txt > Pages : 6 > Date : 17-Jul-01 > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-isis-transient-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-isis-transient-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 16:01:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20008 for ; Wed, 18 Jul 2001 16:01:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59163; Wed, 18 Jul 2001 13:05:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59148 for ; Wed, 18 Jul 2001 13:04:18 -0700 (PDT) Received: from usa04.ambernetworks.com ([63.121.148.133]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6IJunw55664 for ; Wed, 18 Jul 2001 12:56:49 -0700 (PDT) X-JNPR-Received-From: outside Received: by usa04.ambernetworks.com with Internet Mail Service (5.5.2653.19) id <3ZYG76FH>; Wed, 18 Jul 2001 12:58:03 -0700 Message-ID: <9F4704BE89F7D4118A0F0002B328C36C084CF4@usa04.ambernetworks.com> From: Anand Ammundi To: Danny McPherson , isis-wg@juniper.net Subject: RE: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 12:58:02 -0700 Hi I had a question on the IS-IS black-holing subject. IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA (self-lsp/lsa) on an adjacency down/Ckt_down event. yet, many vendors choose not do this...the rationale being that frequent link flapping would result in LSP/LSA storms...but then, not rebuilding one's link-state can cause blackholes just on an adjacency down event. Is there anything among the existing documents that deals with bridging the gap between not wanting to LSP Storm and not wanting blackholes...(say something like BGP dampening). TIA anand -----Original Message----- From: Danny McPherson [mailto:danny@ambernetworks.com] Sent: Wednesday, July 18, 2001 10:58 AM To: isis-wg@juniper.net Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Folks, the only update in this version is the addition of some text surrounding handling of "stale" LSPs. Thanks to Stefano for pointing this out. -danny > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. > > Title : IS-IS Transient Blackhole Avoidance > Author(s) : D. McPherson > Filename : draft-ietf-isis-transient-01.txt > Pages : 6 > Date : 17-Jul-01 > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-isis-transient-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-isis-transient-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 20:27:24 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16201 for ; Wed, 18 Jul 2001 20:27:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA60219; Wed, 18 Jul 2001 17:32:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA60205 for ; Wed, 18 Jul 2001 17:31:38 -0700 (PDT) Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6J0O8w66149 for ; Wed, 18 Jul 2001 17:24:08 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.51.124]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGP00APQ2KCZ7@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Wed, 18 Jul 2001 17:26:37 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt To: Anand Ammundi Cc: Danny McPherson , isis-wg@juniper.net Message-id: <3B562502.655829C7@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <9F4704BE89F7D4118A0F0002B328C36C084CF4@usa04.ambernetworks.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 17:08:34 -0700 Content-Transfer-Encoding: 7BIT Anand Ammundi wrote: > Hi > I had a question on the IS-IS black-holing subject. > IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA > (self-lsp/lsa) > on an adjacency down/Ckt_down event. yet, many vendors > choose not do this...the rationale being that frequent link flapping would > result in LSP/LSA storms...but then, not rebuilding one's link-state > can cause blackholes just on an adjacency down event. Is there anything > among > the existing documents that deals with bridging the gap between not wanting > > to LSP Storm and not wanting blackholes...(say something like BGP > dampening). this is somehow an implementation question so I answer with my personal preference here: I always found that dampening @ protocol level is an inferior solution (BGP is a different case, they dampen prefixes not link flaps!) and it's much better solved closer to the hardware since that can affect many other components beside a single protocol. E.g. dampening @ hardware level (for things like broken fiber 'blinking' and on top of that putting a hysterisis on top of the device driver) has proven much better for me ... -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 20:28:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16364 for ; Wed, 18 Jul 2001 20:28:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA60241; Wed, 18 Jul 2001 17:33:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA55813 for ; Wed, 18 Jul 2001 00:10:41 -0700 (PDT) Received: from hotmail.com (f143.law3.hotmail.com [209.185.241.143]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6I73Iw30154 for ; Wed, 18 Jul 2001 00:03:18 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Jul 2001 00:05:42 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 18 Jul 2001 07:05:41 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2001 07:05:42.0014 (UTC) FILETIME=[0EA249E0:01C10F58] Subject: [Isis-wg] Doubts regarding encapsulation. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 07:05:41 -0000 Hello, I'm a student studying the networking and routing concepts. My doubts are related to the packet formats used for IS-IS PDUs. I had also gone through the RFC 1142 and RFC 1195 for the same. Having gone through the 2 RFCs I am confused as to whether the IS-IS PDUs are encapsulated within the IP datagram or are they encapsulated using CLNP header. If anyone could please tell me as to how does the IS-IS PDU looks like in the physical media (let me be specific to say in ethernet frame). I shall be obliged to get any response on this issue. Thanking you in advance for all the early replies that I get. Sachi _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 22:37:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10346 for ; Wed, 18 Jul 2001 22:37:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA60835; Wed, 18 Jul 2001 19:42:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA60823 for ; Wed, 18 Jul 2001 19:41:55 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6J2YNw69084 for ; Wed, 18 Jul 2001 19:34:23 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6J2aev04455; Wed, 18 Jul 2001 22:36:43 -0400 (EDT) Received: from sevsisters (jlearman-dsl3.cisco.com [10.83.2.140]) by dingdong.cisco.com (Mirapoint) with SMTP id AER04222; Wed, 18 Jul 2001 22:36:41 -0400 (EDT) Message-ID: <009c01c10ffb$9bc6f5c0$8c02530a@sevsisters> From: "Jeff Learman" To: "Sachidananda K" , References: Subject: Re: [Isis-wg] Doubts regarding encapsulation. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 22:36:03 -0400 Content-Transfer-Encoding: 7bit IS-IS PDUs are sent directly over the link layer. For example, on Ethernet, the format is 802.3 MAC header: 6-byte dest MAC address 6-byte src MAC address 2-byte length LLC header: FE (dest LSAP = OSI) FE (src LSAP = OSI) 03 (I frame) IS-IS stuff: 84 (IS-IS NLPID) ... The exceptions to this are (a) partition repair uses IS-IS / CLNP tunnels, but ignore that because it doesn't work (it'll be fixed in next IS-IS version), and (b) there was a draft RFC for IS-IS in IP encapsulation, but that was not popular and I don't recommend it. Jeff ----- Original Message ----- From: Sachidananda K To: Sent: Wednesday, July 18, 2001 3:05 AM Subject: [Isis-wg] Doubts regarding encapsulation. > Hello, > > I'm a student studying the networking and routing concepts. My doubts are > related to the packet formats used for IS-IS PDUs. I had also gone through > the RFC 1142 and RFC 1195 for the same. Having gone through the 2 RFCs I am > confused as to whether the IS-IS PDUs are encapsulated within the IP > datagram or are they encapsulated using CLNP header. If anyone could please > tell me as to how does the IS-IS PDU looks like in the physical media (let > me be specific to say in ethernet frame). > I shall be obliged to get any response on this issue. > > Thanking you in advance for all the early replies that I get. > Sachi > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 23:37:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22751 for ; Wed, 18 Jul 2001 23:37:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61121; Wed, 18 Jul 2001 20:42:17 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61109 for ; Wed, 18 Jul 2001 20:41:49 -0700 (PDT) Received: from smtp.huawei.com (sz135.szptt.net.cn [202.96.135.132] (may be forged)) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f6J41To59585 for ; Wed, 18 Jul 2001 21:01:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from rajeshh ([10.110.8.198]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GGPAUD03.Q0P for ; Thu, 19 Jul 2001 11:25:25 +0800 Message-ID: <003b01c11003$a9b8ee60$c6086e0a@rajeshh> Reply-To: "Rajesh Hegde" From: "Rajesh Hegde" To: Subject: [Isis-wg] - Regarding IS-IS LSP mtu size MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C11046.B7990AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 19 Jul 2001 11:34:05 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C11046.B7990AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Following are the doubts regarding the usage of size of LSP mtu By having default size of 1497 bytes works for most of the data link = types. Ex : Ethernet, FrameRelay and Serial Links where the size of the = DataLink BlockSize is 1500 bytes.=20 =20 1 ) How it should be handled If the datalink type is POS where the = default DataLinkBlockSize is 512 bytes ? 2) How the negotiation of the Hello PDUs to be done in case of FDDI and = Gigabit ethernet where the DataLinkBlockSize is greater than the default = size of 1497 bytes ? (i.e Do we pad the Hello PDU to the size of DataLink Block Size or = increase the LSP MTU size ? )=20 =20 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp = mtu and level 2 lsp-mtu) be made configurable ? Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 = Gigabit ethernet (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 = bytes ) In this case how to decide the size of the LSP-mtu ? Thanks and Regards, Rajesh ------=_NextPart_000_0038_01C11046.B7990AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Following are the doubts regarding = the usage=20 of size of LSP mtu
 
By having default size of 1497 bytes = works for most=20 of the data link types. Ex : Ethernet, FrameRelay and Serial Links where = the=20 size of the DataLink BlockSize is 1500 bytes.
 
1 )  How it should be handled If = the datalink=20 type is POS where the default DataLinkBlockSize is     = 512 bytes=20 ?
 
2) How the negotiation of the Hello = PDUs to be done=20 in case of FDDI and Gigabit ethernet where the DataLinkBlockSize is = greater than=20 the default size of 1497 bytes ?
(i.e Do we pad the Hello PDU to the = size of=20 DataLink Block Size or increase the LSP MTU size ? ) 
 
3) Shall the=20 parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and = level 2=20 lsp-mtu) be made configurable ?
 
Suppose a router with 3 interfaces 1 = ethernet(Link=20 Mtu 1500 bytes), 1 Gigabit ethernet (Link MTU is 9180 bytes), 1 POS = interface (link MTU 512 bytes )
 
In this case how to decide the size of = the LSP-mtu=20 ?
 
Thanks and Regards,
Rajesh
 
 
 
 
------=_NextPart_000_0038_01C11046.B7990AE0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jul 18 23:46:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24897 for ; Wed, 18 Jul 2001 23:46:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61186; Wed, 18 Jul 2001 20:51:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61174 for ; Wed, 18 Jul 2001 20:50:53 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6J3hLw70370 for ; Wed, 18 Jul 2001 20:43:21 -0700 (PDT) X-JNPR-Received-From: outside Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA21246; Wed, 18 Jul 2001 20:45:49 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 20:45:49 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A529@avalon.pluris.com> From: Les Ginsberg To: "'Rajesh Hegde'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Isis-wg] - Regarding IS-IS LSP mtu size MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 18 Jul 2001 20:45:40 -0700 > Hi all, > > Following are the doubts regarding the usage of size of LSP mtu > > By having default size of 1497 bytes works for most of the data link types. Ex : > Ethernet, FrameRelay and Serial Links where the size of the DataLink BlockSize is 1500 > bytes. > > 1 ) How it should be handled If the datalink type is POS where the default > DataLinkBlockSize is 512 bytes ? > The LSP MTU size must be <= to the smallest DataLinkBlockSize(MTU) of any subnetwork over which LSPs are to be propagated. Therefore, if you have even one link with an MTU of 512 over which LSPs will be propagated, then LSP MTU cannot be set larger than 512 in any router in the area/domain. > 2) How the negotiation of the Hello PDUs to be done in case of FDDI and Gigabit > ethernet where the DataLinkBlockSize is greater than the default size of 1497 bytes ? > (i.e Do we pad the Hello PDU to the size of DataLink Block Size or increase the LSP MTU > size ? ) > ISO 10589 is very clear about this. Padding is to the maximum of: o dataLinkBlockSize o originatingL1LSPBufferSize (If L1 routing supported) o originatingL2LSPBUfferSize (If L2 routing supported) See 8.2.3.c and 8.4.2. Setting of the LSP MTU is based NOT upon the dataLinkBlockSize of an individual link but upon the minimum MTU of all links over which LSPs are to be propagated. Since there is no way for the protocol to know this, it is up to the network administartor to configure it correctly and consistently on all routers in the area/domain. > 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and level > 2 lsp-mtu) be made configurable ? > They are configurable. ISO 10589 specifies a range of 512-1492. > Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 Gigabit ethernet > (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 bytes ) > >In this case how to decide the size of the LSP-mtu ? > LSP MTU must be 512 in this case. You may also find the SIF work on this subject of interest: ftp://ftp.juniper.net/pub/isis/lspsize.PDF Apart from the change of the TLVs from 12/13 to a single value of 14, the SIF work as written has been incorporated in the upcoming revision 2 of ISO 10589. > Thanks and Regards, > Rajesh Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 19 08:05:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07532 for ; Thu, 19 Jul 2001 08:05:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA63324; Thu, 19 Jul 2001 05:09:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA63312 for ; Thu, 19 Jul 2001 05:08:03 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6JC0Fw79281 for ; Thu, 19 Jul 2001 05:00:17 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C1104A.B07A648C" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: draft-ietf-isis-auth-anti-replay-00.txt content-class: urn:content-classes:message Thread-Index: AcEQSrBewpbIw8uzR5G/eQfS3Rfnmw== From: "Omer Sali" To: "isis-wg (E-mail)" Subject: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 19 Jul 2001 15:02:31 +0300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1104A.B07A648C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C1104A.B07A648C" ------_=_NextPart_002_01C1104A.B07A648C Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, =20 What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a WG item? =20 Thanks, Omer =20 ------_=_NextPart_002_01C1104A.B07A648C Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Pie Charts
Hi,
 
What is the=20 status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a = WG=20 item?
 
Thanks,
Omer
 
------_=_NextPart_002_01C1104A.B07A648C-- ------_=_NextPart_001_01C1104A.B07A648C Content-Type: image/jpeg; name="Pie Charts Bkgrd.JPG" Content-Transfer-Encoding: base64 Content-ID: <628510112@19072001-0f30> Content-Description: Pie Charts Bkgrd.JPG Content-Location: Pie%20Charts%20Bkgrd.JPG Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QYsUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAAC2AIo/+H/4gL5AkYDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEOAAAAAEAAACAAAAA gAAAAYAAAMAAAAAEHAAYAAH/2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkg QWRvYmUgUGhvdG9zaG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0Q Dg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM /8AAEQgAgACAAwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkK CwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEF QVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKz hMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAME BQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcm NcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eH l6e3x//aAAwDAQACEQMRAD8A7VRTpdlYaqydMnSUukkkgpYpoUgkeElLJJJiipeU0JBOkpinSTlJ SydMnSKn/9DtYShOlCsNVaE0KSUJKYBOpQEiBCClgE5CQScdElKhRI5TymJRUsAnhIJwElLQlCeE ohJS21KEpUhwgVP/0e1TymTKw1WUFNBTSUpKSlEpxqo6lIGOUlM0xTSTwn1hJCySSWiSlJ0yQJSU zSUdQnB0QSojRRlPJShJT//S7VN3SSVhqqckOCnA8UxBSUoGFEqUFLakpiFKUtqRaUkLSmJT7SnD SkpYKQCbaU405SUolMEk6CVJkk6Sn//T7aEoSlKVO1VcJJinCSlinTFP2SUpJKUikpSSZOElKTO+ iU6XKSmNcnlShKAOEphJSiE0J0pSU//U7RJSTHhTtVUpSozrCc8fFJS/KZICE5MhJSwKdNwkDKSF 006pSlKSlElKUkklKlKUk0pKZSlKjPknCSn/1e1SPCeUo0U7VYgd0uU44TgQkpjCUKSaSkpYhNwp gApbQUkMUoUi0BMElLQnhOlKSmJCUKSUJJpjCcBJOCUlP//W7baAmnskCPBMXawp6ai4Tpk6VKUk AoEkHRSBMSkplwmlNJKXKSl5SCUJJKUkkkkpSdNKUlKk2opBJRKVKt//2ThCSU0EBgAAAAAABwAB AAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/7gAOQWRvYmUA ZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCABDAEMDASIAAhEBAxEB/90ABAAF/8QBPwAA AQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQ AAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw 4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIj wVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDuuUylCUKozLJRKQaU 4CSFk0zopaQmA5SStGqSePJKAkpZJPtSSQ//0O7mEpHimKXeeyqMyp1TyOFHtCQkJKXS+KaUh5oK ZAhIx80x8EkUKkpJapJKf//R7uAl5JtUpVRlX7pJgZ1CQKSl9EkyW4pKUAZM8dk5ATbilKSl4STS kkp//9Lu9VED8VLjzSCqMq0FMQVLlPxokphynAKcmUkFLEFNCkkUaUqCklokkp//0+7P0e6S+b0l TZn6O/PTr5wSSQ/SCS+b0kVP0gkvm9JBL9HpL5wSSU//2Q== ------_=_NextPart_001_01C1104A.B07A648C-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 19 10:22:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10684 for ; Thu, 19 Jul 2001 10:22:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA63917; Thu, 19 Jul 2001 07:27:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA63905 for ; Thu, 19 Jul 2001 07:26:04 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6JEIRw83074 for ; Thu, 19 Jul 2001 07:18:27 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Anand Ammundi'" , Danny McPherson , isis-wg@juniper.net Subject: RE: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 19 Jul 2001 10:20:46 -0400 Anand - My understanding on this, as we tried to capture in the I-D below, is that it is crucial to react quickly to down event. This is what prevents black holes. The damping should occur on up-events. If a link has been flapping, the rest of the world will see it as down. If done this way, damping might allow an up link to be thought of as down by those that are not adjacent, but should not allow a down link to be thought of as up. The ID is not currently a work group item, but tries to gather some recommendations in one place. http://search.ietf.org/internet-drafts/draft-parker-short-isis-hold-times-00 .txt - jeff parker - Axiowave Networks > Hi > I had a question on the IS-IS black-holing subject. > IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA > (self-lsp/lsa) > on an adjacency down/Ckt_down event. yet, many vendors > choose not do this...the rationale being that frequent link > flapping would > result in LSP/LSA storms...but then, not rebuilding one's link-state > can cause blackholes just on an adjacency down event. Is > there anything > among > the existing documents that deals with bridging the gap > between not wanting > > to LSP Storm and not wanting blackholes...(say something like BGP > dampening). > TIA > anand > > -----Original Message----- > From: Danny McPherson [mailto:danny@ambernetworks.com] > Sent: Wednesday, July 18, 2001 10:58 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt > > > > Folks, the only update in this version is the addition of some > text surrounding handling of "stale" LSPs. Thanks to Stefano > for pointing this out. > > -danny > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IS-IS for IP Internets > Working Group of > the IETF. > > > > Title : IS-IS Transient Blackhole Avoidance > > Author(s) : D. McPherson > > Filename : draft-ietf-isis-transient-01.txt > > Pages : 6 > > Date : 17-Jul-01 > > > > This document describes a simple, interoperable mechanism > that can be > > employed in IS-IS networks in order to decrease data loss associated > > with deterministic blackholing of packets during transient network > > conditions. The mechanism proposed here requires no IS-IS protocol > > changes and is completely interoperable with the existing IS-IS > > specification. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-isis-transient-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-isis-transient-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 20 08:47:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18268 for ; Fri, 20 Jul 2001 08:47:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA69202; Fri, 20 Jul 2001 05:50:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA69187 for ; Fri, 20 Jul 2001 05:49:54 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6KCg7w25159 for ; Fri, 20 Jul 2001 05:42:07 -0700 (PDT) X-JNPR-Received-From: outside Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 20 Jul 2001 18:23:14 +0530 Received: from amudha (amudha.future.futsoft.com [192.168.5.7]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f6KCi3X32236 for ; Fri, 20 Jul 2001 18:14:03 +0530 Reply-To: From: "Amudhavalli Narayanan" To: Message-Id: <000601c1111a$e88867c0$0705a8c0@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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Help needed for ISIS error message in Cisco router Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 20 Jul 2001 18:23:00 +0530 Content-Transfer-Encoding: 7bit Hi, We are trying an interoperability testing with Cisco. I get the following error message in Cisco router when it receives packets from the router under test "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length invalid from 2101:0102:0304 (Ethernet 1/0). It would be of great help, if someone can throw some light on this error message. Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 20 08:59:55 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20940 for ; Fri, 20 Jul 2001 08:59:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA69285; Fri, 20 Jul 2001 06:05:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA69270 for ; Fri, 20 Jul 2001 06:04:33 -0700 (PDT) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6KCulw25887 for ; Fri, 20 Jul 2001 05:56:47 -0700 (PDT) X-JNPR-Received-From: outside Received: from neserve0.corp.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQkyml15997; Fri, 20 Jul 2001 12:59:20 GMT Received: by neserve0.corp.us.uu.net id QQkyml11167; Fri, 20 Jul 2001 08:59:10 -0400 (EDT) From: jhall@uu.net (Jeremy Hall) Message-Id: Subject: Re: [Isis-wg] Help needed for ISIS error message in Cisco router In-Reply-To: <000601c1111a$e88867c0$0705a8c0@future.futsoft.com> from Amudhavalli Narayanan at "Jul 20, 2001 06:23:00 pm" To: amudha@future.futsoft.com CC: isis-wg@juniper.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 20 Jul 2001 08:59:10 -0400 (EDT) Content-Transfer-Encoding: 7bit GOOD! it seems MTU checking works. ISIS wants the MTU on all interfaces to be the same so it can ensure that packets on a LAN are not dropped. IT means some device is reporting the MTU of 1497 rather than 1500. _J In the new year, Amudhavalli Narayanan wrote: > Hi, > We are trying an interoperability testing with Cisco. I get the following > error message in Cisco router when it receives packets from the router under > test > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > invalid from 2101:0102:0304 (Ethernet 1/0). > > It would be of great help, if someone can throw some light on this error > message. > > Thanks, > Amudha > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 20 09:29:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25821 for ; Fri, 20 Jul 2001 09:29:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA69476; Fri, 20 Jul 2001 06:35:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA69461 for ; Fri, 20 Jul 2001 06:34:30 -0700 (PDT) Received: from redcs4.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6KDQiw27966 for ; Fri, 20 Jul 2001 06:26:44 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redcs4.procket.com (8.9.3/8.9.3) id GAA25651; Fri, 20 Jul 2001 06:29:13 -0700 From: Henk Smit Message-Id: <200107201329.GAA25651@redcs4.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Help needed for ISIS error message in Cisco router To: jhall@uu.net (Jeremy Hall), amudha@future.futsoft.com Cc: isis-wg@juniper.net In-Reply-To: from "Jeremy Hall" at Jul 20, 2001 08:59:10 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 20 Jul 2001 06:29:13 -0700 (PDT) Content-Transfer-Encoding: 7bit > GOOD! it seems MTU checking works. I am not sure what you mean by this. But ISIS implementations should *not* explicitely check the size of incoming hellos to see if they are exactly MTU size. If there is a problem with the reception of packet because of the size, that should be detected via indirect ways. Example, if one router sends hellos that are so big that the interface driver of the other router can not receive them, then of course the ISIS process will never receive the packet either. > ISIS wants the MTU on all interfaces to be the same so it can ensure that > packets on a LAN are not dropped. Huh ? All interfaces of an ISIS router can be configured with a different MTU size. No problem. As long as: 1) all the other routers on those interfaces have matching MTUs configured 2) the MTUs are not smaller than MaxLSPBuffersize (which is typically 1492) > IT means some device is reporting the > MTU of 1497 rather than 1500. > > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > > invalid from 2101:0102:0304 (Ethernet 1/0). Inside the ethernetheader there is a length field. The device your are testing has put value 1497 in there. This seems to be a correct value. 14 bytes ethernet header, 4 bytes CRC, and 3 bytes 802.2 header leave 1497 bytes available from the 1518 bytes in an ethernet frame. Inside the ISIS packets there is a length field too. The device you are testing has put value 1500 in there. This seems wrong. No way you can fit 1500 bytes inside 1497 bytes. Questions like these should typically be directed to the appropriate vendor's support channel (tac@cisco.com). Hope this helps, henk. > _J > > In the new year, Amudhavalli Narayanan wrote: > > Hi, > > We are trying an interoperability testing with Cisco. I get the following > > error message in Cisco router when it receives packets from the router under > > test > > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > > invalid from 2101:0102:0304 (Ethernet 1/0). > > > > It would be of great help, if someone can throw some light on this error > > message. > > > > Thanks, > > Amudha > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 20 14:11:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15178 for ; Fri, 20 Jul 2001 14:11:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA70603; Fri, 20 Jul 2001 11:16:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA70590 for ; Fri, 20 Jul 2001 11:15:16 -0700 (PDT) Received: from usa04.ambernetworks.com ([63.121.148.133]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6KI7Sw40519 for ; Fri, 20 Jul 2001 11:07:28 -0700 (PDT) X-JNPR-Received-From: outside Received: by usa04.ambernetworks.com with Internet Mail Service (5.5.2653.19) id <3ZYG77ZS>; Fri, 20 Jul 2001 11:08:51 -0700 Message-ID: <9F4704BE89F7D4118A0F0002B328C36C084D06@usa04.ambernetworks.com> From: Anand Ammundi To: "'amudha@future.futsoft.com'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Help needed for ISIS error message in Cisco router MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 20 Jul 2001 11:08:43 -0700 Amudha, it might be a bug on your box. basically it is a mismatch between the peers in terms of ethernet 2 and 802.3. ISIS is supported over 802.3. Depending on the value of the type/len field one decides if it is ethernet 2 (type > 1500) or 802.3 (len < 1500) since ethernet 2 type's are always > 1500. since on the cisco the packet has come up as high as IS-IS (judging from the LAN Hello specific error), it has been assumed to be 802.3...so if you have sent it as ethernet 2, you might see this error. thanx anand -----Original Message----- From: Amudhavalli Narayanan [mailto:amudha@future.futsoft.com] Sent: Friday, July 20, 2001 5:53 AM To: isis-wg@juniper.net Subject: [Isis-wg] Help needed for ISIS error message in Cisco router Hi, We are trying an interoperability testing with Cisco. I get the following error message in Cisco router when it receives packets from the router under test "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length invalid from 2101:0102:0304 (Ethernet 1/0). It would be of great help, if someone can throw some light on this error message. Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jul 20 15:32:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13540 for ; Fri, 20 Jul 2001 15:32:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA70966; Fri, 20 Jul 2001 12:37:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA70954 for ; Fri, 20 Jul 2001 12:36:36 -0700 (PDT) Received: from redcs4.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6KJSlw44408 for ; Fri, 20 Jul 2001 12:28:47 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redcs4.procket.com (8.9.3/8.9.3) id MAA14391; Fri, 20 Jul 2001 12:31:10 -0700 From: Henk Smit Message-Id: <200107201931.MAA14391@redcs4.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Help needed for ISIS error message in Cisco router To: Anand@ambernetworks.com (Anand Ammundi) Cc: amudha@future.futsoft.com ('amudha@future.futsoft.com'), isis-wg@juniper.net In-Reply-To: <9F4704BE89F7D4118A0F0002B328C36C084D06@usa04.ambernetworks.com> from "Anand Ammundi" at Jul 20, 2001 11:08:43 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 20 Jul 2001 12:31:09 -0700 (PDT) Content-Transfer-Encoding: 7bit The boundary between length and type encapsulation is not exactly at 1500 bytes. It is somewhere at 1600 or maybe 2000 bytes. (Can't remember). So it is very unlikely that in this case the receiving router is confused about the encapsulation. Also the error message says that the length value inside the ethernet header was 1497 (wire length). So this packet has definitely not been sent using length encapsulation. The error is that the ISIS stack that sent this packet has put the wrong value in the isisheader->packetlength field. henk. > Amudha, > it might be a bug on your box. basically it is a mismatch > between the peers in terms of ethernet 2 and 802.3. > ISIS is supported over 802.3. Depending on the value of the > type/len field one decides if it is ethernet 2 (type > 1500) > or 802.3 (len < 1500) since ethernet 2 type's are always > 1500. > since on the cisco the packet has come up as high as IS-IS (judging > from the LAN Hello specific error), it has been assumed to be > 802.3...so if you have sent it as ethernet 2, you might see this > error. > thanx > anand > > -----Original Message----- > From: Amudhavalli Narayanan [mailto:amudha@future.futsoft.com] > Sent: Friday, July 20, 2001 5:53 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Help needed for ISIS error message in Cisco router > > > Hi, > We are trying an interoperability testing with Cisco. I get the following > error message in Cisco router when it receives packets from the router under > test > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > invalid from 2101:0102:0304 (Ethernet 1/0). > > It would be of great help, if someone can throw some light on this error > message. > > Thanks, > Amudha > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jul 22 05:30:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15204 for ; Sun, 22 Jul 2001 05:30:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA81921; Sun, 22 Jul 2001 02:33:16 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA81909 for ; Sun, 22 Jul 2001 02:32:14 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6M9O8w74930 for ; Sun, 22 Jul 2001 02:24:09 -0700 (PDT) X-JNPR-Received-From: outside content-class: urn:content-classes:message Subject: FW: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: draft-ietf-isis-auth-anti-replay-00.txt Thread-Index: AcEQSrBewpbIw8uzR5G/eQfS3RfnmwCRXEKQ From: "Omer Sali" To: "isis-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id CAA81910 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 22 Jul 2001 12:26:31 +0300 Content-Transfer-Encoding: 8bit Hi, I resend my question, this time in plain text format and not HTML format. What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a WG item? Thanks, Omer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 23 06:36:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08957 for ; Mon, 23 Jul 2001 06:36:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA87883; Mon, 23 Jul 2001 03:41:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA87871 for ; Mon, 23 Jul 2001 03:40:55 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.244]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6NAWdw92604 for ; Mon, 23 Jul 2001 03:32:39 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id DAA16445; Mon, 23 Jul 2001 03:42:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <85191583422.20010723034225@nexsi.com> To: "Omer Sali" CC: "isis-wg (E-mail)" Subject: Re: FW: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 23 Jul 2001 03:42:25 -0700 Content-Transfer-Encoding: 7bit Omer, I was going to get the next version of the doc (intergrating the comments from the WG) prepared before London. We could discuss this topic there and the chairs would decide whether it should be a WG item or not. -- Alex Zinin Sunday, July 22, 2001, 2:26:31 AM, Omer Sali wrote: > Hi, > I resend my question, this time in plain text format and not HTML > format. > What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it > going to be a WG item? > Thanks, > Omer > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 23 13:58:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11115 for ; Mon, 23 Jul 2001 13:58:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA89636; Mon, 23 Jul 2001 11:02:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA89624 for ; Mon, 23 Jul 2001 11:01:20 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6NHr1w08748 for ; Mon, 23 Jul 2001 10:53:01 -0700 (PDT) X-JNPR-Received-From: outside Received: from pots.cisco.com (pots.cisco.com [161.44.224.224]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6NHta509843; Mon, 23 Jul 2001 13:55:36 -0400 (EDT) Received: from oranlt ([161.44.238.34]) by pots.cisco.com (Mirapoint) with ESMTP id AAY01533; Mon, 23 Jul 2001 13:55:24 -0400 (EDT) From: "David R. Oran" To: "'mike shand'" , "'Tony Przygienda'" Cc: Subject: RE: [Isis-wg] FYI: small draft with TLV numbers ... Organization: Cisco Systems Message-ID: <020f01c113a1$cda46510$22ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 23 Jul 2001 14:03:35 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net] On Behalf Of mike shand > Sent: Tuesday, July 17, 2001 2:21 PM > To: Tony Przygienda > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... > > > You missed 42. DECnet PhaseIV :-) > As I recall, that particular value was chosen with care too! > But this is a VERY good idea. Thanks. > > Mike > > At 10:20 17/07/2001 -0700, Tony Przygienda wrote: > >Put a small draft together to prevent TLV conflicts, would > appreciate > >if the word spreads to SIF and OSI so we have a place people > can check > >before steping on each others' toes. > >If missed something or inexact, pls let me know and will > correct and put > >updated version > >out ... > > > > thansk > > > > - tony > > > > > > > > > >Internet Engineering Task Force T. > >Przygienda > >INTERNET DRAFT > >Redback > > > >July 2001 > > Reserved TLV Codepoints in ISIS > > > > > > > > > >Status of This Memo > > > > This document is an Internet-Draft and is in full > conformance with > > all provisions of Section 10 of RFC2026. Internet-Drafts are > >working > > documents of the Internet Engineering Task Force > (IETF), its areas, > > and its working groups. Note that other groups may > also distribute > > working documents as Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > >months > > and may be updated, replaced, or obsoleted by other documents at > > any time. It is inappropriate to use Internet-Drafts > as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > Copyright Notice Copyright (C) The Internet Society (2000). All > > Rights Reserved. > > > > > > > >Abstract > > > > This draft describes implementation codepoints within > > IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for > > routing within their clouds. IS-IS is an interior > gateway routing > > protocol developed originally by OSI and used with IP > extensions as > > IGP. This draft summarizes all TLV codepoints that are > being used > > by > > > > the protocol and its pending extensions. > > > > > >Przygienda Expires Jan 2002 > >[Page 1] > > > >Internet Draft TLV Codepoints > >July 2001 > > > >1. TLV Codepoints reserved > > ___________________________________________________________ > > Name Value IIH LSP SNP Status > > > > ___________________________________________________________ > > > > Area Addresses 1 y y n RFC > > IIS Neighbors 2 n y n RFC > > ES Neighbors 3 n y n RFC > > Part. DIS 4 n y n RFC > > Prefix Neighbors 5 n y n RFC > > IIS Neighbors 6 y n n RFC > > Padding 8 y n n RFC > > LSP Entries 9 n n y RFC > > Authentication 10 y y y IETF-draft > > Opt. Checksum 12 y n y IETF-draft > > LSPBufferSize 14 y? y n SIF-draft > > TE IIS Neigh. 22 n y n IETF-draft > > MT-ISN 222 n y n IETF-draft > > IP Int. Reach 128 n y n RFC > > Prot. Supported 129 y y n RFC > > M-Topologies 229 y y n IETF-draft > > IP Ext. Address 130 n y n RFC > > IDRPI 131 n y y RFC > > IP Intf. Address 132 y y n RFC > > IPv6 Intf. Addr. 232 y y n IETF-draft > > illegal 133 n n n ? > > Router ID 134 n y n IETF-draft > > TE IP. Reach 135 n y n IETF-draft > > MT IP. Reach 235 n y n IETF-draft > > IPv6 IP. Reach 236 n y n IETF-draft > > Dynamic Name 137 n y n RFC > > 3-Way hellos 240 y n n RFC > > > > > > > >2. Assignment Procedures > > > > This document is provided to avoid possible future conflicts in > > assignment of TLV numbers. It does not constitute or > represent any > > standard or authority assigning TLV numbers. TLV assignment > > happens > > > > on a shared, informational basis between the ISO, SIF > and the IETF > > working groups. The core ISIS protocol is being > specified in the > > ISO standards body, IP extensions to it however are > products of the > > ISIS working group in IETF. Since ISO does not provide > a numbering > > authority and IANA is only responsible for IP related coding > > points, > > > > > > > >Przygienda Expires Jan 2002 > >[Page 2] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > no plausible central authority to assign TLV numbers > exists as of > > today. > > > > > > > >3. Acknowledgments > > > >4. Security Consideration > > > > ISIS security applies to the work presented. No > specific security > > issues are being introduced. > >References > > > > [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. > > INTERNET-RFC, Internet Engineering Task > Force, February > > 1990. > > > > > > [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and > > Dual > > > > Environments. INTERNET-RFC, Internet Engineering Task > > Force, December 1990. > > > > > > [ISO90] ISO. Information Technology - Telecommunications and > > Information Exchange between Systems - Intermediate > > System > > > > to Intermediate System Routing Exchange Protocol for > > Use in Conjunction with the Protocol for Providing the > > Connectionless-Mode Network Service. ISO, 1990. > > > > > > > >5. Authors' Addresses > > > > Tony Przygienda > > Redback Networks > > 350 Holger Way > > San Jose, CA, 95134-1362 > > prz@redback.com > > > > > > > >6. Full Copyright Statement > > > > Copyright (C) The Internet Society (1997). All Rights Reserved. > > > > This document and translations of it may be copied and > furnished to > > others, and derivative works that comment on or > otherwise explain > > it > > > > or assist in its implementation may be prepared, > copied, published > > and distributed, in whole or in part, without restriction of any > > kind, provided that the above copyright notice and this > paragraph > > are included on all such copies and derivative works. However, > >Przygienda Expires Jan 2002 > >[Page 3] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > this document itself may not be modified in any way, such as by > > removing the copyright notice or references to the > Internet Society > > or other Internet organizations, except as needed for > the purpose > > of developing Internet standards in which case the procedures > > for copyrights defined in the Internet Standards process must be > > followed, or as required to translate it into languages > other than > > English. > > > > The limited permissions granted above are perpetual and > will not be > > revoked by the Internet Society or its successors or assigns. > > > > This document and the information contained herein is > provided on > > an > > > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING > > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING > > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > > >Przygienda Expires Jan 2002 > >[Page 4] > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/i> sis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 23 18:15:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27690 for ; Mon, 23 Jul 2001 18:15:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA90739; Mon, 23 Jul 2001 15:20:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA90724 for ; Mon, 23 Jul 2001 15:19:04 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6NMAiw21293 for ; Mon, 23 Jul 2001 15:10:44 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 1B48426280A for ; Mon, 23 Jul 2001 15:13:28 -0700 (PDT) Message-ID: <3B5C9D35.6B9B6BF@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] agenda ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 23 Jul 2001 14:55:02 -0700 Content-Transfer-Encoding: 7bit Didn't see the slot yet but we better start on the agenda items, mails to me pls --- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 23 18:39:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28572 for ; Mon, 23 Jul 2001 18:39:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA90925; Mon, 23 Jul 2001 15:45:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA90910 for ; Mon, 23 Jul 2001 15:44:14 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6NMZrw22417 for ; Mon, 23 Jul 2001 15:35:53 -0700 (PDT) X-JNPR-Received-From: outside Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoLV-0003hG-00; Mon, 23 Jul 2001 15:38:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] agenda ... References: <3B5C9D35.6B9B6BF@redback.com> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 23 Jul 2001 15:38:37 -0700 Content-Transfer-Encoding: 7bit > Didn't see the slot yet wed 09:00-11:30 randy _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 24 06:34:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06794 for ; Tue, 24 Jul 2001 06:34:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA93855; Tue, 24 Jul 2001 03:37:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA93843 for ; Tue, 24 Jul 2001 03:36:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6OARbw38287 for ; Tue, 24 Jul 2001 03:27:37 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05870; Tue, 24 Jul 2001 06:29:25 -0400 (EDT) Message-Id: <200107241029.GAA05870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Jul 2001 06:29:25 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Reserved TLV Codepoints in ISIS Author(s) : T. Przygienda Filename : draft-ietf-isis-wg-tlv-codepoints-00.txt Pages : Date : 23-Jul-01 This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-tlv-codepoints-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 24 09:46:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17523 for ; Tue, 24 Jul 2001 09:46:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA94661; Tue, 24 Jul 2001 06:50:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA94646 for ; Tue, 24 Jul 2001 06:49:05 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6ODebw42047 for ; Tue, 24 Jul 2001 06:40:37 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Lakshminarayanan Rajamanickam'" Cc: "'isis-wg@juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: ISIS over NBMA Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Jul 2001 09:43:17 -0400 I will try the third question > 3) In RFC-2973, ISIS Mesh Groups (page#4), > How the numbered mesh groups are connected by "transit circuits" > Let's consider a full-mesh topology with three routers A, B, C is divided in to two mesh groups 1 & 2 (full-mesh) > mesh group 1: A and B > mesh group 2: B and C > here B is the transit router whose both interfaces are 'meshset' > and if the interface link between A and C is 'meshblocked' > then where comes the transit interface ? > any response in this regard would be of great helpful > thanks in advance, > lakshminarayan r You assume a full mesh of three routers. The routers themselves are not in mesh groups: the circuits are. It is easy to configure mesh groups on the network below so it is not connected. One way to configure it so that it is connected would be to meshblock circuits v and x, and to put the circuits w and y in different mesh groups. This configuration is brittle: breaking either link AB or BC will disconnect the network, as link AC does not carry LSPs. A u v / \ / \ w x B y ----- z C There are more examples in the RFC to check out: mesh groups become more interesting as N gets much bigger than 3. In the example above, if there is any router that uses mesh groups to reduce flooding, then we can break a single link and break flooding. If there are 4 routers in a full mesh, it is possible to reduce flooding without risking disconnection through a single link failure. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 24 18:51:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29763 for ; Tue, 24 Jul 2001 18:51:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA96835; Tue, 24 Jul 2001 15:57:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA96823 for ; Tue, 24 Jul 2001 15:56:06 -0700 (PDT) Received: from smtp.huawei.com (sz135.szptt.net.cn [202.96.135.132] (may be forged)) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6OMkow67713; Tue, 24 Jul 2001 15:46:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from narayananl ([10.110.8.191]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GGZ1TQ00.W2T; Tue, 24 Jul 2001 17:46:38 +0800 Message-ID: <001901c11426$45b531e0$bf086e0a@narayananl> Reply-To: "Lakshminarayanan Rajamanickam" From: "Lakshminarayanan Rajamanickam" To: Cc: , , Organization: FS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C11469.5305DFA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Isis-wg] ISIS over NBMA Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Jul 2001 17:51:54 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C11469.5305DFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi,=20 1) How the ISIS treats NBMA networks? as a multi-access network or as a = collection of point-to-point links or both ? 2) If the NBMA network is considered as a collection of logical p2p = sub-interfaces (s0.1, s0.2, s0.3, ....) only then, how the PDUs are exchanged over a physical interface(s0). In this case = ISIS PDUs are need to be processed similar=20 to point-to-point links ? or any parent-child relationship needs to be = maintained between the sub-interfaces and=20 the physical interface to track ? 3) In RFC-2973, ISIS Mesh Groups (page#4),=20 How the numbered mesh groups are connected by "transit circuits"=20 Let's consider a full-mesh topology with three routers A, B, C is = divided in to two mesh groups 1 & 2 (full-mesh) mesh group 1: A and B mesh group 2: B and C here B is the transit router whose both interfaces are 'meshset' and if the interface link between A and C is 'meshblocked' then where comes the transit interface ? any response in this regard would be of great helpful=20 thanks in advance, lakshminarayan r ------=_NextPart_000_0016_01C11469.5305DFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 
1) How the ISIS treats NBMA = networks? as=20 a multi-access network or as a collection of point-to-point links or = both=20 ?
 
2) If the NBMA network is considered as = a=20 collection of logical p2p sub-interfaces (s0.1, s0.2, s0.3, ....) only=20 then,
how the PDUs are exchanged over a = physical=20 interface(s0). In this case ISIS PDUs = are need to=20 be processed similar
to point-to-point links ? or any = parent-child=20 relationship needs to be maintained between the sub-interfaces and =
the physical interface to track = ?
 
3) In RFC-2973, ISIS Mesh Groups = (page#4),=20
How the numbered mesh groups are = connected by=20 "transit circuits"
 
Let's consider a full-mesh = topology with=20 three routers A, B, C is divided in to two mesh groups 1 & 2=20 (full-mesh)
 
mesh group 1: A and B
mesh group 2: B and C
 
here B is the transit router whose=20 both interfaces are 'meshset'
and if the interface link between A and = C is=20 'meshblocked'
then where comes the transit interface=20 ?
 
any response in this regard would be of = great=20 helpful 
 
thanks in advance,
lakshminarayan r
 
------=_NextPart_000_0016_01C11469.5305DFA0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jul 26 14:36:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02175 for ; Thu, 26 Jul 2001 14:36:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA07349; Thu, 26 Jul 2001 11:39:23 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA07337 for ; Thu, 26 Jul 2001 11:38:16 -0700 (PDT) Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6QITMw47258 for ; Thu, 26 Jul 2001 11:29:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.49.212]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GH30096WFHPAD@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 26 Jul 2001 11:32:14 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3B605DCE.A3C8EBA5@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=iso-8859-1 X-Accept-Language: en Subject: [Isis-wg] draft-ietf-isis-transient last call recall (total recall ? ;-) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 26 Jul 2001 11:13:35 -0700 X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id LAA07349 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA02175 draft-ietf-isis-transient-01.txt underwent a change significant enough to justify another 2 weeks period till 8/12 for a last call. Comments pls to the list. From what I saw it's really just one paragraph but anyone who read -00 and cared will be easily able to figure out where it is ... Comment here (not sure it deserves inclusion since it's a tad of a hair-split): Seems to me seeting the OVLD bit and setting all outgoing links to inf (as described in alternative) is NOT entirely the same thing if traffic _originates_ @ the very router or a directly attached subnet. When OVLD bit is set, the router should be able to forward to the rest of the network, if all its outgoing links are (true) infinity, it will not since it sees the network unreachable. Leaving one link smaller than inf solves the problem partially but there is no guarantee the whole network can be reached by that very link. This observation may be significant for I-BGP session origination on this very router unless I missed something here. -- tony =================================================== Network Working Group Danny McPherson INTERNET DRAFT Amber Networks, Inc. July 2001 IS-IS Transient Blackhole Avoidance 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. McPherson, D. [Page 1] INTERNET DRAFT July 2001 3. Introduction When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which had previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g., BGP) destination networks. When the previously failed router becomes available again, in only a few seconds paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g., learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded. A simple interoperable mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below. 4. Discussion This document describes a simple, interoperable mechanism that can be employed in IS-IS [1, 2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge. The benefits of such a mechanism can realized when considering the following scenario depicted in Figure 1. McPherson, D. [Page 2] INTERNET DRAFT July 2001 D.1 | +-------+ | RtrD | +-------+ / \ / \ +-------+ +-------+ | RtrB | | RtrC | +-------+ +-------+ \ / \ / +-------+ | RtrA | +-------+ | S.1 Figure 1: Example Network Topology Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destina­ tion D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path. Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD. Assume now that RtrB comes back online. In only a few seconds IS-IS neighbor state has been established with RtrA and RtrD and database syn­ chronization has occurred. RtrA now realizes that the best path to des­ tination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronization it's BGP neighbor rela­ tionship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. If RtrB were to temporarily set it's LSP Overload bit while synchroniz­ ing BGP tables with it's neighbors, RtrA would continue to use the work­ ing RtrA->RtrC->RtrD path, and the LSP should only be used to obtain McPherson, D. [Page 3] INTERNET DRAFT July 2001 reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). However, it should be noted that when RtrB goes away its LSP is still present in the IS-IS databases of all other routers in the routing domain. When RtrB comes back it establishes adjacencies. As soon as its neighbors have an adjacency with RtrB, they will advertise their new adjacency in their new LSP. The result is that all the other routers will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, even though RtrB is still completing its synchronization and therefore has not yet sent it's new LSP yet. At this time SPF is computed and everyone will include RtrB in their tree since they will use the old version of RtrB LSP (the new one has not yet arrived). Once RtrB has finished establishing all its adjacen­ cies, it will then regenerate its LSP and flood it. Then all other routers within the domain will finally compute SPF with the correct information. Only at that time will the Overload bit be taken into account. As such, it is recommended that each time a router establishes an adja­ cency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used. After synchronization of BGP tables with neighboring routers (or expiry of some other timer or trigger), RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB. Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise it's own loopback (or similar) IP address, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It's because of this that sim­ ply flooding an empty LSP is not sufficient. McPherson, D. [Page 4] INTERNET DRAFT July 2001 5. Deployment Considerations Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing the usefulness obtained from that of the IS-IS Overload bit technique. This mechanism has been deployed in several large IS-IS networks for a number of years. Triggers for setting the Overload bit as described are left to the implementer. Some potential triggers could perhaps include "N sec­ onds after booting", or "N number of BGP prefixes in the BGP Loc- RIB". Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the desti­ nation network, employing such a mechanism may actually have a nega­ tive impact on convergence (i.e., the router maintains the only available path to reach downstream routers, but the Overload bit dis­ allows other nodes in the network from calculating paths via the router, and as such, no feasible path exists to the routers). Finally, if all systems within an IS-IS routing domain haven't imple­ mented the Overload bit correctly, forwarding loops may occur. 6. Potential Alternatives Alternatively, it may be considered more appealing to employ some­ thing more akin to [3] for this purpose. With this model, during transient conditions a node advertises excessively high link metrics to serve as an indication to other nodes in the network that paths transiting the router are "less desirable" than existing paths. The advantage of a metric-based mechanism over the Overload bit mech­ anism proposed here model is that transit paths may still be calcu­ lated through the router. Another advantage is that a metric- based mechanism does not require that all nodes in the IS-IS domain cor­ rectly implement the Overload bit. However, as currently deployed, IS-IS provides for only 6 bits of space for link metric allocation, and 10 bits aggregate path metric. Though extensions proposed in [4] remove this limitation, they've not yet been widely deployed. As such, there's currently little flexi­ bility when using link metrics for this purpose. Of course, both McPherson, D. [Page 5] INTERNET DRAFT July 2001 methods proposed in this document are backwards-compatible. 7. Security Considerations The mechanisms specified in this memo introduces no new security issues to IS-IS. 8. Acknowledgements The author of this document makes no claim to the originality of the idea. Thanks to Stefano Previdi for valuable feedback on the mecha­ nism discussed in this document. 9. 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] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Retana et al., "OSPF Stub Router Advertisement", RFC 3137, June 2001. [4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress. 10. Author's Address Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Email: danny@ambernetworks.com McPherson, D. [Page 6] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jul 28 20:44:03 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12712 for ; Sat, 28 Jul 2001 20:44:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA16686; Sat, 28 Jul 2001 03:14:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA16674 for ; Sat, 28 Jul 2001 03:13:08 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6SA42w50337 for ; Sat, 28 Jul 2001 03:04:02 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id DAA18241; Sat, 28 Jul 2001 03:08:24 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <3041383065.20010728030649@nexsi.com> To: Tony Przygienda CC: isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-transient last call recall (total recall ? ;-) In-Reply-To: <3B605DCE.A3C8EBA5@redback.com> References: <3B605DCE.A3C8EBA5@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 28 Jul 2001 03:06:49 -0700 X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id DAA16686 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA12712 Tony, Regarding the infinity thing. The solution that was actually described in the initial version of the OSPF doc, but was then taken out is to originate two LSAs/LSPs---one for the LSDB and neighbors and one for yourself, which you do not install in the LSDB, but use for Dijkstra as the root vertex. The difference between the two is that the external version has infinite costs and the internal has real ones. Wrt the draft: Danny, fix the paragraphs! :) -- Alex Zinin Thursday, July 26, 2001, 11:13:35 AM, Tony Przygienda wrote: > draft-ietf-isis-transient-01.txt underwent a change significant > enough to justify another 2 weeks period till 8/12 > for a last call. Comments > pls to the list. From what I saw it's really just one paragraph but > anyone who read -00 and cared will be easily able to figure out > where it is ... > Comment here (not sure it deserves inclusion since it's a tad of a > hair-split): Seems to me seeting > the OVLD bit and setting all outgoing links to inf > (as described in alternative) is NOT entirely > the same thing if traffic _originates_ @ the very router or a directly > attached subnet. When OVLD bit > is set, the router should be able to forward to the rest of the > network, if all its outgoing links are (true) infinity, it will not > since it > sees the network unreachable. Leaving one link smaller than inf > solves the problem partially but there is no guarantee the whole > network can be reached by that very link. This observation may > be significant for I-BGP session origination on this very router > unless I missed something here. > -- tony > =================================================== > Network Working Group Danny McPherson > INTERNET DRAFT Amber Networks, Inc. > July 2001 > IS-IS Transient Blackhole Avoidance > > 1. Status of this Memo > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > 2. Abstract > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > McPherson, D. [Page 1] > INTERNET DRAFT July 2001 > 3. Introduction > When an IS-IS router that was previously a transit router becomes > unavailable as a result of some transient condition such as a reboot, > other routers within the routing domain must select an alternative > path to reach destinations which had previously transited the failed > router. Presumably, the newly selected router(s) comprising the path > have been available for some time and, as a result, have complete > forwarding information bases (FIBs) which contain a full set of > reachability information for both internal and external (e.g., BGP) > destination networks. > When the previously failed router becomes available again, in only a > few seconds paths that had previously transited the router are again > selected as the optimal path by the IGP. As a result, forwarding > tables are updated and packets are once again forwarded along the > path. Unfortunately, external destination reachability information > (e.g., learned via BGP) is not yet available to the router, and as a > result, packets bound for destinations not learned via the IGP are > unnecessarily discarded. > A simple interoperable mechanism to alleviate the offshoot associated > with this deterministic behavior is discussed below. > 4. Discussion > This document describes a simple, interoperable mechanism that can be > employed in IS-IS [1, 2] networks in order to avoid transition to a > newly available path until other associated routing protocols such as > BGP have had sufficient time to converge. > The benefits of such a mechanism can realized when considering the > following scenario depicted in Figure 1. > McPherson, D. [Page 2] > INTERNET DRAFT July 2001 > D.1 > | > +-------+ > | RtrD | > +-------+ > / \ > / \ > +-------+ +-------+ > | RtrB | | RtrC | > +-------+ +-------+ > \ / > \ / > +-------+ > | RtrA | > +-------+ > | > S.1 > Figure 1: Example Network Topology > Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->>RtrB->RtrD. Routers A, B and C learn of reachability to destina­ > tion D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected > because when calculating the path to BGP NEXT_HOP of RtrD the sum of the > IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of > the metrics of the RtrA-RtrC-RtrD path. > Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is > used. Once RtrA's FIB is updated and it begins forwarding packets to > RtrC everything should behave properly as RtrC has existing forwarding > information regarding destination D.1's availability via BGP NEXT_HOP > RtrD. > Assume now that RtrB comes back online. In only a few seconds IS-IS > neighbor state has been established with RtrA and RtrD and database syn­ > chronization has occurred. RtrA now realizes that the best path to des­ > tination D.1 is via RtrB, and therefore updates it FIB appropriately. > RtrA begins to forward packets destined to D.1 to RtrB. Though, because > RtrB has yet to establish and synchronization it's BGP neighbor rela­ > tionship and routing information with RtrD, RtrB has no knowledge > regarding reachability of destination D.1, and therefore discards the > packets received from RtrA destined to D.1. > If RtrB were to temporarily set it's LSP Overload bit while synchroniz­ > ing BGP tables with it's neighbors, RtrA would continue to use the work­ ing RtrA->>RtrC->RtrD path, and the LSP should only be used to obtain > McPherson, D. [Page 3] > INTERNET DRAFT July 2001 > reachability to locally connected networks (rather than for calculating > transit paths through the router, as defined in [1]). > However, it should be noted that when RtrB goes away its LSP is still > present in the IS-IS databases of all other routers in the routing > domain. When RtrB comes back it establishes adjacencies. As soon as its > neighbors have an adjacency with RtrB, they will advertise their new > adjacency in their new LSP. The result is that all the other routers > will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, > even though RtrB is still completing its synchronization and therefore > has not yet sent it's new LSP yet. > At this time SPF is computed and everyone will include RtrB in their > tree since they will use the old version of RtrB LSP (the new one has > not yet arrived). Once RtrB has finished establishing all its adjacen­ > cies, it will then regenerate its LSP and flood it. Then all other > routers within the domain will finally compute SPF with the correct > information. Only at that time will the Overload bit be taken into > account. > As such, it is recommended that each time a router establishes an adja­ > cency, it will update its LSP and flood it immediately, even before > beginning database synchronization. This will allow for the Overload bit > setting to propagate immediately, and remove the potential for an older > version of the reloaded routers LSP to be used. > After synchronization of BGP tables with neighboring routers (or expiry > of some other timer or trigger), RtrB would generate a new LSP, clearing > the Overload bit, and RtrA could again begin using the optimal path via > RtrB. > Typically, in service provider networks IBGP connections are done via > peerings with 'loopback' addresses. As such, the newly available router > must advertise it's own loopback (or similar) IP address, as well as > associated adjacencies, in order to make the loopbacks accessible to > other routers within the routing domain. It's because of this that sim­ > ply flooding an empty LSP is not sufficient. > McPherson, D. [Page 4] > INTERNET DRAFT July 2001 > 5. Deployment Considerations > Such a mechanism increases overall network availability and allows > network operators to alleviate the deterministic blackholing behavior > introduced in this scenario. Similar mechanisms [3] have been > defined for OSPF, though only after realizing the usefulness obtained > from that of the IS-IS Overload bit technique. > This mechanism has been deployed in several large IS-IS networks for > a number of years. > Triggers for setting the Overload bit as described are left to the > implementer. Some potential triggers could perhaps include "N sec­ > onds after booting", or "N number of BGP prefixes in the BGP Loc- > RIB". > Unlike similar mechanisms employed in [3], if the Overload bit is set > in a router's LSP, NO transit paths are calculated through the > router. As such, if no alternative paths are available to the desti­ > nation network, employing such a mechanism may actually have a nega­ > tive impact on convergence (i.e., the router maintains the only > available path to reach downstream routers, but the Overload bit dis­ > allows other nodes in the network from calculating paths via the > router, and as such, no feasible path exists to the routers). > Finally, if all systems within an IS-IS routing domain haven't imple­ > mented the Overload bit correctly, forwarding loops may occur. > 6. Potential Alternatives > Alternatively, it may be considered more appealing to employ some­ > thing more akin to [3] for this purpose. With this model, during > transient conditions a node advertises excessively high link metrics > to serve as an indication to other nodes in the network that paths > transiting the router are "less desirable" than existing paths. > The advantage of a metric-based mechanism over the Overload bit mech­ > anism proposed here model is that transit paths may still be calcu­ > lated through the router. Another advantage is that a metric- based > mechanism does not require that all nodes in the IS-IS domain cor­ > rectly implement the Overload bit. > However, as currently deployed, IS-IS provides for only 6 bits of > space for link metric allocation, and 10 bits aggregate path metric. > Though extensions proposed in [4] remove this limitation, they've not > yet been widely deployed. As such, there's currently little flexi­ > bility when using link metrics for this purpose. Of course, both > McPherson, D. [Page 5] > INTERNET DRAFT July 2001 > methods proposed in this document are backwards-compatible. > 7. Security Considerations > The mechanisms specified in this memo introduces no new security > issues to IS-IS. > 8. Acknowledgements > The author of this document makes no claim to the originality of the > idea. Thanks to Stefano Previdi for valuable feedback on the mecha­ > nism discussed in this document. > 9. 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] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > [3] Retana et al., "OSPF Stub Router Advertisement", RFC 3137, June > 2001. > [4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", > Work in Progress. > 10. Author's Address > Danny McPherson > Amber Networks, Inc. > 48664 Milmont Drive > Fremont, CA 94538 > Email: danny@ambernetworks.com > McPherson, D. [Page 6] > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jul 28 20:44:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12721 for ; Sat, 28 Jul 2001 20:44:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA13931; Fri, 27 Jul 2001 15:49:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA13919 for ; Fri, 27 Jul 2001 15:48:23 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6RMdMw13675 for ; Fri, 27 Jul 2001 15:39:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04287 for ; Fri, 27 Jul 2001 15:42:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@juniper.net From: Micah Bartell Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 27 Jul 2001 17:42:16 -0500 Folks, I have made the latest revision of ISO 10589v2 and the Disposition of Comments file available. They are both located at ftp.cisco.com/pub/rfc/ISO/ The file names are: ISO 10589v2: ISO10589v2-2001-07-04.pdf Comments: DoC-2001-07-04.pdf If anyone has any comments to make, I will be accepting comments for two weeks before beginning the process in the ISO to move forward toward FDIS. /mpb _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 14:52:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15412 for ; Mon, 30 Jul 2001 14:52:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA31948; Mon, 30 Jul 2001 11:58:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA99161 for ; Wed, 25 Jul 2001 01:47:18 -0700 (PDT) Received: from hotmail.com (f90.law3.hotmail.com [209.185.241.90]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6P8cXw82377 for ; Wed, 25 Jul 2001 01:38:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jul 2001 01:41:22 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 25 Jul 2001 08:41:21 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2001 08:41:22.0226 (UTC) FILETIME=[94F56120:01C114E5] Subject: [Isis-wg] IS-IS on IP v4 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Jul 2001 08:41:21 +0000 Sir, Thanks a lot for having clarified my doubt related to encapsulation. I have another question related to the IS-IS for IP V4. I had read through the RFC 1195 which defines TLVs for incorporating IP specific information into IS-IS PDUs. My Question: Do we exceute the SPF algorithm separately for OSI and IP. I understand that different forwarding database are maintained for IP and OSI reoutes. Like wise, do we also have different adjacency database for OSI and IP or is it one and the same for the 2 protocols. I don't know as to whether it is implementation specific aspect and the implementer is free to implement either way. Is there any standard rule for this. if so, could you please let me know about the same. I shall be obliged to get any response on this regards. Thanking you in advance for all the early replies that I get. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 14:53:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15533 for ; Mon, 30 Jul 2001 14:53:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA31976; Mon, 30 Jul 2001 12:00:28 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA16728 for ; Sat, 28 Jul 2001 03:17:39 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6SA8Vw50357 for ; Sat, 28 Jul 2001 03:08:32 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id PAA18269; Sat, 28 Jul 2001 15:33:32 +0530 From: "Sivakumar A" Message-Id: <200107281003.PAA18269@WS0005.indiatimes.com> To: "workgroup" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549" MIME-Version: 1.0 Subject: [Isis-wg] Multiple CSNPs problem Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 28 Jul 2001 15:39:59 +0530 --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549 Content-Type: text/plain; charset=us-ascii Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549 Content-Type: text/html; charset=us-ascii

Hello all,

Kindly clarify the following :

In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this.

Thanks and regards

Sivakumar A

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 14:54:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15548 for ; Mon, 30 Jul 2001 14:54:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA31997; Mon, 30 Jul 2001 12:00:49 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA24677 for ; Sun, 29 Jul 2001 05:06:32 -0700 (PDT) Received: from web11201.mail.yahoo.com (web11201.mail.yahoo.com [216.136.131.171]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6TBvFw64184 for ; Sun, 29 Jul 2001 04:57:15 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: <20010729120016.74152.qmail@web11201.mail.yahoo.com> Received: from [202.9.170.10] by web11201.mail.yahoo.com; Sun, 29 Jul 2001 05:00:16 PDT From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-971280378-996408016=:72090" Subject: [Isis-wg] ISIS-BGP interaction Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 29 Jul 2001 05:00:16 -0700 (PDT) --0-971280378-996408016=:72090 Content-Type: text/plain; charset=us-ascii Hi, Is there any standard document, defining the interaction between integrated ISIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was that earlier (upto 94) there were references to ISIS-BGP interaction.But after that it was not mentioned at all.In july 94 meeting's minutes,it was mentioned that the status of ISIS-BGP interaction document is unknown and it needs to be published as as draft\rfc.Can I get more information on this issue. Aravind --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-971280378-996408016=:72090 Content-Type: text/html; charset=us-ascii

Hi,

Is there any standard document, defining the interaction between integrated ISIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was that earlier (upto 94) there were references to ISIS-BGP interaction.But after that it was not mentioned at all.In july 94 meeting's minutes,it was mentioned that the status of ISIS-BGP interaction document is unknown and it needs to be published as as draft\rfc.Can I get more information on this issue.

Aravind


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-971280378-996408016=:72090-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 15:07:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16276 for ; Mon, 30 Jul 2001 15:07:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA32091; Mon, 30 Jul 2001 12:14:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA32079 for ; Mon, 30 Jul 2001 12:13:39 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6UJ49w98460 for ; Mon, 30 Jul 2001 12:04:09 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Sivakumar A'" Cc: "'isis-wg@juniper.net'" Subject: RE: [Isis-wg] Multiple CSNPs problem MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jul 2001 15:06:53 -0400 Two comments The transmission of CSNPs on a LAN is done by the "Designated IS", so at least one of your two routers can be silent A CSNP includes information on which part of the LSP DB it covers. Thus the reciever will not set SRM bits for LSPs that fall outside the scope of a CSNP. - jeff parker - axiowave networks - diagnostic: someone who doesn't believe in two gods From: Sivakumar A [mailto:sivaa@indiatimes.com] Sent: Saturday, July 28, 2001 6:10 AM To: workgroup Subject: [Isis-wg] Multiple CSNPs problem Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 15:43:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18689 for ; Mon, 30 Jul 2001 15:43:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA32369; Mon, 30 Jul 2001 12:50:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA32354 for ; Mon, 30 Jul 2001 12:49:31 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6UJe0w00156 for ; Mon, 30 Jul 2001 12:40:01 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A9649CAB72; Mon, 30 Jul 2001 12:43:05 -0700 (PDT) To: Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] ISIS-BGP interaction In-reply-to: Mail from Aravind Ravikumar dated Sun, 29 Jul 2001 05:00:16 PDT <20010729120016.74152.qmail@web11201.mail.yahoo.com> From: Naiming Shen Message-Id: <20010730194305.A9649CAB72@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jul 2001 12:43:05 -0700 http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 16:33:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22541 for ; Mon, 30 Jul 2001 16:33:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32609; Mon, 30 Jul 2001 13:39:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32597 for ; Mon, 30 Jul 2001 13:38:02 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6UKSVw02333 for ; Mon, 30 Jul 2001 13:28:31 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 45290 invoked from network); 30 Jul 2001 20:31:35 -0000 Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 30 Jul 2001 20:31:35 -0000 From: "Ken Larmer" To: "Sivakumar A" , "workgroup" Subject: RE: [Isis-wg] Multiple CSNPs problem Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01C11915.535FA7F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200107281003.PAA18269@WS0005.indiatimes.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jul 2001 16:33:12 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0112_01C11915.535FA7F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sivakumar, Each CSNP contains a Start and End LSP range. If a received CSNP does not contain a LSP entry within the given range (non-referenced LSP), the receiving IS should set the SRMflag and clear the SSNflag. When minimumBroadcastLSPTransmissionInterval (33 milliseconds) expires, scan the LSP database looking for LSPs with the SRMflag set. Once one is found, transmit the LSP on the appropriate circuit. The next scan of the LSP database commences once minimumBroadcastLSPTransmissionInterval expires again and should continue from the last LSP transmitted. When a second CSNP for the same level is received, this CSNP will also contain a Start and End LSP range. Repeat the steps above until all LSP entries have been processed. Hope this helps??? Cheers, Ken Larmer -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sivakumar A Sent: Saturday, July 28, 2001 6:10 AM To: workgroup Subject: [Isis-wg] Multiple CSNPs problem Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A ---------------------------------------------------------------------------- -- Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com ------=_NextPart_000_0112_01C11915.535FA7F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sivakumar,
 
   =20 Each CSNP contains a Start and End LSP range. If a received CSNP does = not=20 contain a LSP entry within the given range (non-referenced LSP), the = receiving=20 IS should set the SRMflag and clear the SSNflag. When=20 minimumBroadcastLSPTransmissionInterval (33 milliseconds) = expires, scan the=20 LSP database looking for LSPs with the SRMflag set. Once one is found, = transmit=20 the LSP on the appropriate circuit. The next scan of the LSP=20 database commences once minimumBroadcastLSPTransmissionInterval=20 expires again and should continue from the last LSP=20 transmitted.
 
   =20 When a second CSNP for the same level is received, this CSNP will also = contain a=20 Start and End LSP range. Repeat the steps above until all LSP entries = have been=20 processed. Hope this helps???
 
Cheers,
Ken=20 Larmer
 
 -----Original = Message-----
From:=20 isis-wg-admin@external.juniper.net=20 [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sivakumar = A
Sent: Saturday, July 28, 2001 6:10 AM
To:=20 workgroup
Subject: [Isis-wg] Multiple CSNPs=20 problem

Hello all,

Kindly clarify the following :

In a broadcast circuit consider 2 Intermediate Systems having the = same=20 contents in their respective LSP databases. At every CSNP interval = each needs=20 to transmit CSNP with the set of LSPs in its database. Considering the = number=20 of LSPs in the database, there may be more than one CSNP required to = be=20 transmitted. If the number of LSPs in the database is more then more = than one=20 CSNP is required to be transmitted. In this case first CSNP contains = only a=20 portion of the LSPs in its database. If this CSNP is received by other = Intermediate system, it sets the SRM flags for the LSPs which are = not=20 listed in the CSNP received. Kindly clarify this.

Thanks and regards

Sivakumar A

 

Get Your Private, Free E-mail from = Indiatimes at=20 http://email.indiatimes.com
Buy Music, = Video, CD-ROM=20 and Audio-Books from http://www.planetmonline.com = ------=_NextPart_000_0112_01C11915.535FA7F0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 16:42:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23126 for ; Mon, 30 Jul 2001 16:42:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32674; Mon, 30 Jul 2001 13:48:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32662 for ; Mon, 30 Jul 2001 13:47:11 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6UKbew02700 for ; Mon, 30 Jul 2001 13:37:40 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 32952 invoked from network); 30 Jul 2001 20:40:45 -0000 Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 30 Jul 2001 20:40:45 -0000 From: "Ken Larmer" To: "Micah Bartell" , Subject: RE: [Isis-wg] ISO 10589v2 Latest Revision Document Availability Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jul 2001 16:42:21 -0400 Content-Transfer-Encoding: 7bit Hi Micah, Is the ISO-10589V2 document you referenced in your email the same as the Second Edition 2001-04-12 ISO-1589 document available on the jtc1sc06.org web page? The reason I ask is because the version on the jtc1sc06.org web page is in a MSWord format, which makes it easier to search for desired text. Cheers, Ken Larmer > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Micah Bartell > Sent: Friday, July 27, 2001 6:42 PM > To: isis-wg@juniper.net > Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability > > > Folks, > > I have made the latest revision of ISO 10589v2 and the Disposition of > Comments file available. > > They are both located at ftp.cisco.com/pub/rfc/ISO/ > > The file names are: > > ISO 10589v2: ISO10589v2-2001-07-04.pdf > Comments: DoC-2001-07-04.pdf > > If anyone has any comments to make, I will be accepting comments for two > weeks before beginning the process in the ISO to move forward toward FDIS. > > /mpb > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jul 30 16:51:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23838 for ; Mon, 30 Jul 2001 16:51:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32738; Mon, 30 Jul 2001 13:57:18 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32726 for ; Mon, 30 Jul 2001 13:56:20 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6UKknw03161 for ; Mon, 30 Jul 2001 13:46:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA22771; Mon, 30 Jul 2001 13:49:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20010730154850.029e4740@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Micah Bartell Subject: RE: [Isis-wg] ISO 10589v2 Latest Revision Document Availability Cc: In-Reply-To: References: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jul 2001 15:49:48 -0500 It is different. The difference is specified in the Disposition of Comments file. I will add the word copy to the ftp site. /mpb At 16:42 07/30/2001 -0400, Ken Larmer wrote: >Hi Micah, > > Is the ISO-10589V2 document you referenced in your email the same > as the >Second Edition >2001-04-12 ISO-1589 document available on the jtc1sc06.org web page? The >reason I ask is because the version on the jtc1sc06.org web page is in a >MSWord format, which makes it easier to search for desired text. > >Cheers, >Ken Larmer > > > -----Original Message----- > > From: isis-wg-admin@external.juniper.net > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Micah Bartell > > Sent: Friday, July 27, 2001 6:42 PM > > To: isis-wg@juniper.net > > Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability > > > > > > Folks, > > > > I have made the latest revision of ISO 10589v2 and the Disposition of > > Comments file available. > > > > They are both located at ftp.cisco.com/pub/rfc/ISO/ > > > > The file names are: > > > > ISO 10589v2: ISO10589v2-2001-07-04.pdf > > Comments: DoC-2001-07-04.pdf > > > > If anyone has any comments to make, I will be accepting comments for two > > weeks before beginning the process in the ISO to move forward toward FDIS. > > > > /mpb > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 11:02:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19826 for ; Tue, 31 Jul 2001 11:02:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37365; Tue, 31 Jul 2001 08:08:18 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37353 for ; Tue, 31 Jul 2001 08:07:19 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21501; Tue, 31 Jul 2001 17:00:42 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010731165502.03b00e38@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Sachidananda K" From: stefano previdi Subject: Re: [Isis-wg] Dual IS-IS 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 16:58:11 +0200 At 16:48 31/07/2001, Sachidananda K wrote: >Hello, > >I have some doubts related to the the working of dual IS-IS. > >My question: >Is the link state database maintained seperately for both OSI addresses >and IP addresses or is it one and the same. Topology database and shortest path tree computation is a matter of implementation as long as the Dijkstra algorithm is used consistently across the whole area/domain. You may want to have different topologies for different address families (IPv4, IPv6, OSI, ucast/mcast, QoS, ...). s. >I am not aware of any standard or draft giving any clue about this. Please >help me understand this aspect of IS-IS. > >I shall be obliged to get an early help in this respones. > >Thanking in advance for all the responses. >Sachi > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 11:08:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20331 for ; Tue, 31 Jul 2001 11:08:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37438; Tue, 31 Jul 2001 08:15:18 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37423 for ; Tue, 31 Jul 2001 08:14:24 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Sachidananda K'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Dual IS-IS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 11:07:41 -0400 > Is the link state database maintained seperately for both OSI > addresses and IP addresses or is it one and the same. > > Sachi The link state database exchange and storage mechanism is agnostic about the contents of PDUs. IP and OSI information can live in the same Link State PDU. No attempt is made to determine the domain of such information until the SPF algorithm inspects the PDUs. The SPF computation is described in section 3.10 of RFC 1195, http://ietf.org/rfc/rfc1195.txt - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 11:10:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20443 for ; Tue, 31 Jul 2001 11:10:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA37267; Tue, 31 Jul 2001 07:56:18 -0700 (PDT) Received: from hotmail.com (f94.law3.hotmail.com [209.185.241.94]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA37255 for ; Tue, 31 Jul 2001 07:55:03 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Jul 2001 07:48:32 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 31 Jul 2001 14:48:32 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jul 2001 14:48:32.0738 (UTC) FILETIME=[DEA53C20:01C119CF] Subject: [Isis-wg] Dual IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 14:48:32 +0000 Hello, I have some doubts related to the the working of dual IS-IS. My question: Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. I am not aware of any standard or draft giving any clue about this. Please help me understand this aspect of IS-IS. I shall be obliged to get an early help in this respones. Thanking in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 11:51:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22652 for ; Tue, 31 Jul 2001 11:51:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37760; Tue, 31 Jul 2001 08:57:19 -0700 (PDT) Received: from web11206.mail.yahoo.com (web11206.mail.yahoo.com [216.136.131.188]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA37748 for ; Tue, 31 Jul 2001 08:56:14 -0700 (PDT) Message-ID: <20010731154939.80126.qmail@web11206.mail.yahoo.com> Received: from [202.9.170.10] by web11206.mail.yahoo.com; Tue, 31 Jul 2001 08:49:39 PDT From: Aravind Ravikumar Subject: Re: [Isis-wg] ISIS-BGP interaction To: isis-wg@spider.juniper.net In-Reply-To: <20010730194305.A9649CAB72@prattle.redback.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1805583877-996594579=:79826" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 08:49:39 -0700 (PDT) --0-1805583877-996594579=:79826 Content-Type: text/plain; charset=us-ascii Thanks for the reply,I would to like get some more clarification on the issue I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP IN the charter of Inter-Domain Routing (idr) working group there is a reference to BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents. From what I infer This has been published as rfc 1745.I believe that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and"The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.) respectievely Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the document and I think, the document you are mentioning is also about OSPF-BGP/IDRP interaction More specifcally my questions are In an ASBR which uses BGP as the EGP and ISIS as the IGP, How does BGP learn about the destinations that are reachable inside this autonomous sytem How does the ISIS obtain information about AS external destinations Aravind Naiming Shen wrote: http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-1805583877-996594579=:79826 Content-Type: text/html; charset=us-ascii

 Thanks for the reply,I would to like get some more clarification on the issue

I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP

IN  the charter of Inter-Domain Routing (idr) working group there is a reference to
BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents.

From what I infer This has been published as rfc 1745.I believe that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and"The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.)  respectievely

 Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the document and I think, the document you are mentioning is also about OSPF-BGP/IDRP interaction

More specifcally my questions are

In an ASBR which uses BGP as the EGP and ISIS as the IGP,

How does BGP learn about the destinations that are reachable inside this  autonomous sytem

 How does the ISIS obtain information about AS external destinations

Aravind

Naiming Shen <naiming@redback.com> wrote:


http://www.ietf.org/IESG/actions.html


BGP4/IDRP for IP---OSPF Interaction (Historic)

]
]Hi,
]
]Is there any standard document, defining the interaction between integrated I
SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone
through the minutes of ISIS working group .The strange thing I noticed was tha
t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha
t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha
t the status of ISIS-BGP interaction document is unknown and it needs to be pub
lished as as draft\rfc.Can I get more information on this issue.
]
]Aravind
]

- Naiming


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-1805583877-996594579=:79826-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 13:54:36 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03490 for ; Tue, 31 Jul 2001 13:54:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA38317; Tue, 31 Jul 2001 11:00:18 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA38299 for ; Tue, 31 Jul 2001 10:59:44 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VHr2511977; Tue, 31 Jul 2001 13:53:02 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AGK01159; Tue, 31 Jul 2001 13:53:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20010731125657.01ea8588@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Sachidananda K" From: Jeff Learman Subject: Re: [Isis-wg] Dual IS-IS Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 13:05:33 -0400 From an external perspective, the LSP database for OSI and IP is integrated -- that is, the LSPs can carry both types of information, and the ordering rules apply to IS and ES Neighbors options without regard for protocol, and the IS and ES Neighbors options do not indicate which protocol they apply to (according to RFC 1195, that is handled by the "protocols supported" options in conjunction with the deployment rules). And an IS is required to save all LSPs verbatim -- at least they must appear to do so from external behavior, e.g., when sending another system's LSP to a neighbor because of the information in the neighbor's SNPs. While some system may choose to place certain IP information in different LSP numbers than OSI information, there are limitations to what they could do because of special requirements for LSP zero -- you can't have an OSI LSP zero and an IP LSP zero unless you're running completely separate instances of ISIS (and let's not go there, because this is not an advanced course). Regards, Jeff Opinions expressed are not necessarily those of my employer, and I am not working in IS-IS at Cisco. At 10:48 AM 7/31/2001, Sachidananda K wrote: >Hello, > >I have some doubts related to the the working of dual IS-IS. > >My question: >Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. I am not aware of any standard or draft giving any clue about this. Please help me understand this aspect of IS-IS. > >I shall be obliged to get an early help in this respones. > >Thanking in advance for all the responses. >Sachi > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 15:38:47 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14573 for ; Tue, 31 Jul 2001 15:38:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38689; Tue, 31 Jul 2001 12:19:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38677 for ; Tue, 31 Jul 2001 12:18:01 -0700 (PDT) Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f6VJ8Kw42582 for ; Tue, 31 Jul 2001 12:08:20 -0700 (PDT) X-JNPR-Received-From: outside Received: from nexthop.com ([64.211.218.17]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f6VJBJJ51217; Tue, 31 Jul 2001 15:11:21 -0400 (EDT) (envelope-from naamato@nexthop.com) Received: (from naamato@localhost) by nexthop.com (8.11.0/8.11.0) id f6VJBGt20091; Tue, 31 Jul 2001 15:11:16 -0400 (EDT) From: Nick Amato To: isis-wg@juniper.net Cc: Nick Amato Message-ID: <20010731151116.B325@wooj.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Isis-wg] comment on hmac-03 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 15:11:16 -0400 It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt needs clarification. If a router restarts when it's time to use a new key, let's first assume it rolls over its link, area and domain keys. In this case the rolling-over router will not become adjacent with neighbors using the old link key and thus will not receive its old LSP. Section 2.1 seems to refer to the case where a router changes only, for example, its area key and not its link key. In this case the rolling-over router may become adjacent with neighbor(s) that are still using the old area key. This case seems more like a misconfiguration to me as an IS is allowed to accept more than a single key at once. Nick Amato NextHop Technologies _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 20:25:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08131 for ; Tue, 31 Jul 2001 20:25:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA39977; Tue, 31 Jul 2001 17:31:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA39965 for ; Tue, 31 Jul 2001 17:30:11 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f710KTw55682 for ; Tue, 31 Jul 2001 17:20:29 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 5B4D31DCC6A; Tue, 31 Jul 2001 17:23:37 -0700 (PDT) To: Nick Amato Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] comment on hmac-03 In-reply-to: Mail from Nick Amato dated Tue, 31 Jul 2001 15:11:16 EDT <20010731151116.B325@wooj.nexthop.com> From: Naiming Shen Message-Id: <20010801002337.5B4D31DCC6A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 17:23:37 -0700 ] ]It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt ]needs clarification. ] ]If a router restarts when it's time to use a new key, let's first assume ]it rolls over its link, area and domain keys. In this case the rolling-over ]router will not become adjacent with neighbors using the old link key and ]thus will not receive its old LSP. ] ]Section 2.1 seems to refer to the case where a router changes only, ]for example, its area key and not its link key. In this case the ]rolling-over router may become adjacent with neighbor(s) that are ]still using the old area key. ] ]This case seems more like a misconfiguration to me as an IS is allowed ]to accept more than a single key at once. ] An implementation of ISIS authentication does not have to use a single key for the whole box. Actually each link can have it's own keys, and even on each routing level of the link. Users may want to do authentication only on the LSP packets but not other ISIS packets. Or a user may want to do simple authentication on one link and hmac on the others. But you are right, if the whole box uses a single key to rollover for all ISIS packets, the case in 2.1 should not occur. thanks. ]Nick Amato ]NextHop Technologies ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 20:36:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09182 for ; Tue, 31 Jul 2001 20:36:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA40077; Tue, 31 Jul 2001 17:43:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA40065 for ; Tue, 31 Jul 2001 17:42:43 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f710X1w56005 for ; Tue, 31 Jul 2001 17:33:01 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 3E5444BA21A; Tue, 31 Jul 2001 17:36:09 -0700 (PDT) To: Nick Amato Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] comment on hmac-03 In-reply-to: Mail from Naiming Shen dated Tue, 31 Jul 2001 17:23:37 PDT <20010801002337.5B4D31DCC6A@prattle.redback.com> From: Naiming Shen Message-Id: <20010801003609.3E5444BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 17:36:09 -0700 Actually, even if the whole box uses a single key, this problem can still occur. The section 2.1 is talking about a case where a key(assume for all the isis packets) is rolled over at time X, and ISIS process of router A restarted at that time. All the adjacencies should still come up fine to use the new key. But the router can not send out it's LSP out since it's neighbors still have A's old LSP(which has higher seq #), but router A can't advance it's seq# because it can not authenticate the old LSP it's neighbors send it back. ] ] ] ]It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt ] ]needs clarification. ] ] ] ]If a router restarts when it's time to use a new key, let's first assume ] ]it rolls over its link, area and domain keys. In this case the rolling-ove r ] ]router will not become adjacent with neighbors using the old link key and ] ]thus will not receive its old LSP. ] ] ] ]Section 2.1 seems to refer to the case where a router changes only, ] ]for example, its area key and not its link key. In this case the ] ]rolling-over router may become adjacent with neighbor(s) that are ] ]still using the old area key. ] ] ] ]This case seems more like a misconfiguration to me as an IS is allowed ] ]to accept more than a single key at once. ] ] ] ]An implementation of ISIS authentication does not have to use a single ]key for the whole box. Actually each link can have it's own keys, and ]even on each routing level of the link. Users may want to do authentication ]only on the LSP packets but not other ISIS packets. Or a user may want to ]do simple authentication on one link and hmac on the others. But you are ]right, if the whole box uses a single key to rollover for all ISIS packets, ]the case in 2.1 should not occur. ] ]thanks. ] ] ]Nick Amato ] ]NextHop Technologies ] ]_______________________________________________ ] ]Isis-wg mailing list - Isis-wg@external.juniper.net ] ]http://external.juniper.net/mailman/listinfo/isis-wg ] ]- Naiming - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 21:05:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11495 for ; Tue, 31 Jul 2001 21:05:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA40254; Tue, 31 Jul 2001 18:12:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA40242 for ; Tue, 31 Jul 2001 18:11:07 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7111Pw56820 for ; Tue, 31 Jul 2001 18:01:25 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 837591DCC6D; Tue, 31 Jul 2001 18:04:30 -0700 (PDT) Message-ID: <3B67513B.48E61147@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Naiming Shen Cc: Nick Amato , isis-wg@juniper.net Subject: Re: [Isis-wg] comment on hmac-03 References: <20010801003609.3E5444BA21A@prattle.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 17:45:47 -0700 Content-Transfer-Encoding: 7bit Naiming Shen wrote: > Actually, even if the whole box uses a single key, this problem can > still occur. > > The section 2.1 is talking about a case where a key(assume for all > the isis packets) is rolled over at time X, and ISIS process of router A > restarted at that time. All the adjacencies should still come up fine > to use the new key. But the router can not send out it's LSP out since > it's neighbors still have A's old LSP(which has higher seq #), but > router A can't advance it's seq# because it can not authenticate the > old LSP it's neighbors send it back. well, isn't the idea of a 'roll-over' that you accept both keys for a period of time? And during this period of time all LSPs with the old key should time out and any other possible information authenticated by this key should also vanish so obviously roll-over period >> LSP lifetime. Also you must be able within ISIS to hold both keys and when you receive a piece of information, try new key and then old key. Given that, what's the problem exactly ? -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 22:45:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18885 for ; Tue, 31 Jul 2001 22:45:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA40695; Tue, 31 Jul 2001 19:52:18 -0700 (PDT) Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA40683 for ; Tue, 31 Jul 2001 19:51:48 -0700 (PDT) Received: from nexthop.com ([64.211.218.17]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f712j6J66701; Tue, 31 Jul 2001 22:45:06 -0400 (EDT) (envelope-from naamato@nexthop.com) Received: (from naamato@localhost) by nexthop.com (8.11.0/8.11.0) id f712j6s25315; Tue, 31 Jul 2001 22:45:06 -0400 (EDT) From: Nick Amato To: isis-wg@spider.juniper.net Cc: prz@redback.com, naiming@redback.com Subject: Re: [isis-wg] comment on hmac-03 Message-ID: <20010731224351.A25225@wooj.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 22:43:51 -0400 > > Actually, even if the whole box uses a single key, this problem can > > still occur. > > > > The section 2.1 is talking about a case where a key(assume for all > > the isis packets) is rolled over at time X, and ISIS process of router A > > restarted at that time. All the adjacencies should still come up fine > > to use the new key. But the router can not send out it's LSP out since > > it's neighbors still have A's old LSP(which has higher seq #), but > > router A can't advance it's seq# because it can not authenticate the > > old LSP it's neighbors send it back. > > well, isn't the idea of a 'roll-over' that you accept both keys for a period > of time? And during this period of time all LSPs with the old key should > time out and any other possible information authenticated by this key > should also vanish so obviously roll-over period >> LSP lifetime. > Also you must be able within ISIS to hold both keys > and when you receive a piece of information, try new key and then old > key. Given that, what's the problem exactly ? Just to be clear, multiple-key 'roll-over' is, according to the draft, an optional part of this authentication (...the router MAY check a set of passwords when verifying the Authentication value). The problem I was addressing is that section 2.1 is unclear. It should not apply to a router that implements 'roll-over' as you define it above, rather to a case where a router can become adjacent with N neighbors but cannot authenticate LSP packets from any of them. Whether the router restarts or not is irrelevant. Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's even useful to talk about LSPs here since, potentially, the router may not be able to authenticate CSNs from the DISs (or have other routers authenticate its CSN if it is a DIS on a circuit). Nick _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 23:39:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22940 for ; Tue, 31 Jul 2001 23:39:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA40959; Tue, 31 Jul 2001 20:46:19 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA40946 for ; Tue, 31 Jul 2001 20:45:18 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 509A04BA21A; Tue, 31 Jul 2001 20:38:43 -0700 (PDT) To: Nick Amato Cc: isis-wg@spider.juniper.net, prz@redback.com Subject: Re: [isis-wg] comment on hmac-03 In-reply-to: Mail from Nick Amato dated Tue, 31 Jul 2001 22:43:51 EDT <20010731224351.A25225@wooj.nexthop.com> From: Naiming Shen Message-Id: <20010801033843.509A04BA21A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 20:38:43 -0700 ] ]> > Actually, even if the whole box uses a single key, this problem can ]> > still occur. ]> > ]> > The section 2.1 is talking about a case where a key(assume for all ]> > the isis packets) is rolled over at time X, and ISIS process of router A ]> > restarted at that time. All the adjacencies should still come up fine ]> > to use the new key. But the router can not send out it's LSP out since ]> > it's neighbors still have A's old LSP(which has higher seq #), but ]> > router A can't advance it's seq# because it can not authenticate the ]> > old LSP it's neighbors send it back. ]> ]> well, isn't the idea of a 'roll-over' that you accept both keys for a perio d ]> of time? And during this period of time all LSPs with the old key should ]> time out and any other possible information authenticated by this key ]> should also vanish so obviously roll-over period >> LSP lifetime. ]> Also you must be able within ISIS to hold both keys ]> and when you receive a piece of information, try new key and then old ]> key. Given that, what's the problem exactly ? ] ]Just to be clear, multiple-key 'roll-over' is, according to the draft, an ]optional part of this authentication (...the router MAY check a set ]of passwords when verifying the Authentication value). Tony was right that in a multiple-key 'rollover', if the old key is kept around long enough, this case should not happen. This can happen if in the 'rollover', the new key replaces the old key, or the old key is not kept long enough. Or this can happen with a single key, all the routers are configured to use authentication at time X, one router crashes right after X, and in this case, there is no "old" key. ] ]The problem I was addressing is that section 2.1 is unclear. It ]should not apply to a router that implements 'roll-over' as you ]define it above, rather to a case where a router can become adjacent ]with N neighbors but cannot authenticate LSP packets from any of them. ]Whether the router restarts or not is irrelevant. ] ]Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's ]even useful to talk about LSPs here since, potentially, the router ]may not be able to authenticate CSNs from the DISs (or have other routers ]authenticate its CSN if it is a DIS on a circuit). I'm not sure what's this to do with csns or dis. this was not saying LSPs are using a diff key. let's try the following case with just two routers: A and B, they use authentication for all packets. before time X, they use key1, after time X, they use key2. At time X, both A and B switches auth key from key1 into key2, and A's ISIS process restarted. A and B then re-establish the adjacency with the key2, they can also exchange the SNPs using the key2, there is no problem of that. A now has a LSP starts from seq# of 1. when A sends this LSP to B, B rejects this, and send the A's old LSP back to A(with the key1). If B does not have multiple-key implemented or B timedout the key1 too soon, then the old LSP with key1 is rejected because of failing authentication. B will not get A's new LSP until this old LSP of A timed out. ] ]Nick - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jul 31 23:50:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23713 for ; Tue, 31 Jul 2001 23:50:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA41056; Tue, 31 Jul 2001 20:57:19 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA41044 for ; Tue, 31 Jul 2001 20:56:38 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A155A1DCC63; Tue, 31 Jul 2001 20:50:02 -0700 (PDT) To: Nick Amato Cc: isis-wg@spider.juniper.net, prz@redback.com Subject: Re: [isis-wg] comment on hmac-03 In-reply-to: Mail from Naiming Shen dated Tue, 31 Jul 2001 20:38:43 PDT <20010801033843.509A04BA21A@prattle.redback.com> From: Naiming Shen Message-Id: <20010801035002.A155A1DCC63@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 20:50:02 -0700 ] ]At time X, both A and B switches auth key from key1 into key2, and A's ]ISIS process restarted. A and B then re-establish the adjacency with ]the key2, they can also exchange the SNPs using the key2, there is no ]problem of that. A now has a LSP starts from seq# of 1. when A sends ]this LSP to B, B rejects this, and send the A's old LSP back to A(with ]the key1). If B does not have multiple-key implemented or B timedout typo here ^ (should be A) ^ ( A also ) ]the key1 too soon, then the old LSP with key1 is rejected because of ]failing authentication. B will not get A's new LSP until this old LSP ]of A timed out. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg