From isis-wg-bounces@ietf.org Tue Jul 04 21:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxwQD-0006ao-FP; Tue, 04 Jul 2006 21:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxwQC-0006Tg-HO for isis-wg@ietf.org; Tue, 04 Jul 2006 21:43:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxuxO-0000HV-D3 for isis-wg@ietf.org; Tue, 04 Jul 2006 20:09:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxukT-0005F5-Tr for isis-wg@ietf.org; Tue, 04 Jul 2006 19:56:13 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Jul 2006 16:56:07 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k64Nu7H0023013; Tue, 4 Jul 2006 16:56:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k64Nu69s013415; Tue, 4 Jul 2006 16:56:06 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jul 2006 16:56:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Tue, 4 Jul 2006 16:56:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Thread-Index: AcaXIhbccEQgeqFiSIGTrw9ptNbMcgIm0o/Q From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" , "Stefano Previdi \(sprevidi\)" X-OriginalArrivalTime: 04 Jul 2006 23:56:06.0742 (UTC) FILETIME=[6A4CA760:01C69FC5] DKIM-Signature: a=rsa-sha1; q=dns; l=7709; t=1152057367; x=1152921367; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=22Les=20Ginsberg=20\(ginsberg\)=22=20 |Subject:RE=3A=20[Isis-wg]=20Update=20to=20Multi-instance=20Multi-Topology=20Draf t=20available; X=v=3Dcisco.com=3B=20h=3DznkOvryiKj28s9WfTD24XS+M1zg=3D; b=TevTkOg0ZUnNUTrXKEUWRzIdC5ab6vyb+cqyIct/gVP+fUPQkqqlscn8mJAKxMtLhrbMdZGM 7nHMIDT4xx+pK9GWdaPczovEyPOrHxSPxQFe1uH33Weg1mm73xXQ6JyJ; Authentication-Results: sj-dkim-3.cisco.com; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.0 (--) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - Here is a more complete reply to the points you have raised. By way of preface, assume that an MI-capable router will use a different system ID for non-zero IID instances than it does for the instance associated with IID #0. We don't state this in the draft, but it is not prohibited either. In consideration of the points you raise, it is probably a good practice - and a future version of the draft will discuss this. What this means is that even in the contexts you raise below, in the unlikely event a legacy router receives an IS-IS PDU associated w a non-zero IID, it will always be seen as having originated from a system which is unreachable in the IID #0 topology. Therefore, such a PDU will not alter routing behavior in the IID #0 topology. More detailed responses inline. > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Friday, June 23, 2006 5:07 PM > To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi) > Cc: isis mailing list > Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft > available >=20 >=20 >=20 > Les Ginsberg (ginsberg) wrote: >=20 > > We gave a lot of thought to backwards compatibility - and discussed > > those issues in the draft. If you are not convinced we considered all > > issues, please point out a specific problem (or problems) that you > > believe we overlooked. >=20 > i don't think the restrictions on p2p interfaces will practically > work. - there is all sort of real-world strangeness (reconfig, APS) > that could break this. it is easy to makeup a series of events > where e.g. a LSP from a non-zero instance could end-up in instance 0. >=20 The window of opportunity here is the time between the "strange event" and the receipt of the first hello (which, due to 3way handshake logic, will cause the adjacency to be reinitialized). Should a non-zero IID LSP or SNP PDU arrive, it could find its way into the legacy router's LSPDB. However as the originating system will be unreachable (due to the different system ID used for non-zero) this will not affect routing in IID #0 topology. It is also worth mentioning that the same sort of event could happen today even without MI extensions. For example, if A has a neighbor B on a P2P. The "strange event" happens and A is now connected to C on the same interface. A could receive an LSP from C prior to the reception of an IIH. This LSP could be added to A's LSPDB. If C were in a different area, this might not be appropriate.=20 So MI does not introduce a new risk here - and with the use a different system ID for non-zero instances the dangers are certainly no greater than in current deployments. > >> we should not use subnet dependend fields (like MAC adresses) > >> to control the versioning. > > > > > > That isn't what we are doing. We use a different MAC address to insure > > that legacy implementations won't see the PDUs they cannot correctly > > process. The protocol behavior hasn't changed at all - but we do need a > > way to allow multiple instances to run on a LAN and be invisible to > > legacy implementations. >=20 > there is an underlying assumption that implementations actually parse > the dest-MAC adress for sanitizing the PDU. if memory serves me correct > then iso10589 does not contain a sanity check rule that requires > to check the destination-MAC adress against the configured Level. >=20 > in addition i know of at least two widely deployed implementations that > do not do, or did not do this ;-) > Your answer to a follow up question from me indicates that we agree that incoming multicast PDUs pass through a lower level address filter before being delivered to IS-IS code. Therefore, the use of a new multicast destination address will prevent legacy implementations from ever seeing an IS-IS PDU associated with a non-zero IID which is sent on a LAN. Your concern seems to be that in order to support MI extensions, some implementations might have to modify hard coded filter logic which might be part of the kernel code. So this isn't an interoperability concern, but rather a concern on your part that the MI implementation cost in some cases could be higher than you would like. I invite other folks on the list to indicate whether this is a significant concern. =20 > >>since this is a essentially a redefinition of > >> all known TLVs [which are from now on now keyed by the instance-id] > >> have you thought about using a different PDU version in the IS-IS > >> common header ? > >> > >> suggestion: > >> pdu-version 1 would be used for topology 0 [fully downwards > >> compatible] and > >> pdu-version 2 would be used for the per-instance-keyed > >> topologies. > >> > >> all PDU type and TLV allocations stay as-is. > >> > >> that way you rule out any subnet specific dependencies and any node > >> that does not understand pdu-version 2 will ignore it anyway, which > is > >> IMO a cleaner transition tool. >=20 > > One of the wonderful things about IS-IS is that it has survived for a > > long time now and has been extended in many ways without need for a new > > protocol version. Such robustness is to be respected and not discarded > > lightly. Spinning a new version is a major step and one which the > > community has thus far consciously avoided - with good reason I think. > > I see nothing in the proposal which suggests this is a desirable > > approach, let alone necessary. But, I'll keep listening... >=20 > TLVs are fine for doing incremental changes - but what you are suggesting > here is to change the semantics of every TLV ever defined (which is to > be keyed by the instance-id) - if you want to do that in a clean way > then you need IMO redefine all TLVs (undesirable) or bump the pdu version > field. - I stand by my previous comments regarding a new protocol version. Spinning a new protocol version quite rightly demands a higher set of requirements than is generally applied to releasing a new version of a software implementation. Given that this would be the first new version in the history of the IS-IS protocol, it is reasonable to assume that before taking such a step we would solicit requests for other changes which might be incorporated at the same time. (I am sure many of us have a few things which we might like to see...) Based on the experience of other protocols, I am guessing a few years from now we might have reached agreement. Of course, noting that in this case the base spec is owned by ISO (not IETF), it might take a bit longer. :-) It is legitimate to debate whether MI can be supported in an interoperable way in the current protocol version. If the collective wisdom of the WG is "no", then I think MI gets thrown onto the pile of things that shouldn't be done now. >=20 >=20 > >>finally a question: how would i link nodes between different > >> topologies if i wanted to do so ? >=20 > > This sounds like a trick question. :-) >=20 > oh it isn't - i just wanted to check if there is a way to keep seperate > topologies and still have them connected on a choke point. >=20 > --- >=20 > another question which i don't really understand: >=20 > what problem does MI solve that cannot be solved using MT ? > (apart from the 12-Bit vs. 16-Bit Topology/Instance space > difference). > MI solves the same problem as MT, but it allows for a greater degree of fault isolation. This has been a significant concern for some in the community. YMMV Les =20 >=20 > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jul 05 06:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4rI-0006UR-CX; Wed, 05 Jul 2006 06:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4rG-0006UH-ST for isis-wg@ietf.org; Wed, 05 Jul 2006 06:43:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4BS-0002iq-NP for isis-wg@ietf.org; Wed, 05 Jul 2006 06:00:38 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy3wT-0005nU-OX for isis-wg@ietf.org; Wed, 05 Jul 2006 05:45:11 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k659j8622751; Wed, 5 Jul 2006 11:45:08 +0200 (CEST) Received: from [144.254.191.203] (dhcp-144-254-191-203.cisco.com [144.254.191.203]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k659j6C05225; Wed, 5 Jul 2006 11:45:06 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Wed, 5 Jul 2006 11:45:11 +0200 To: "Les Ginsberg \(ginsberg\)" X-Mailer: Apple Mail (2.623) X-Spam-Score: -2.6 (--) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Hannes Gredler , isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org On Jul 5, 2006, at 1:56 AM, Les Ginsberg ((ginsberg)) wrote: > Hannes - > > Here is a more complete reply to the points you have raised. > > By way of preface, assume that an MI-capable router will use a > different > system ID for non-zero IID instances than it does for the instance > associated with IID #0. We don't state this in the draft, but it is not > prohibited either. In consideration of the points you raise, it is > probably a good practice - and a future version of the draft will > discuss this. > > What this means is that even in the contexts you raise below, in the > unlikely event a legacy router receives an IS-IS PDU associated w a > non-zero IID, it will always be seen as having originated from a system > which is unreachable in the IID #0 topology. Therefore, such a PDU will > not alter routing behavior in the IID #0 topology. > > More detailed responses inline. > >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Friday, June 23, 2006 5:07 PM >> To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi) >> Cc: isis mailing list >> Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft >> available >> >> >> >> Les Ginsberg (ginsberg) wrote: >> >>> We gave a lot of thought to backwards compatibility - and discussed >>> those issues in the draft. If you are not convinced we considered > all >>> issues, please point out a specific problem (or problems) that you >>> believe we overlooked. >> >> i don't think the restrictions on p2p interfaces will practically >> work. - there is all sort of real-world strangeness (reconfig, APS) >> that could break this. it is easy to makeup a series of events >> where e.g. a LSP from a non-zero instance could end-up in instance 0. >> > > The window of opportunity here is the time between the "strange event" > and the receipt of the first hello (which, due to 3way handshake logic, > will cause the adjacency to be reinitialized). Should a non-zero IID > LSP > or SNP PDU arrive, it could find its way into the legacy router's > LSPDB. > However as the originating system will be unreachable (due to the > different system ID used for non-zero) this will not affect routing in > IID #0 topology. > > It is also worth mentioning that the same sort of event could happen > today even without MI extensions. For example, if A has a neighbor B on > a P2P. The "strange event" happens and A is now connected to C on the > same interface. A could receive an LSP from C prior to the reception of > an IIH. This LSP could be added to A's LSPDB. If C were in a different > area, this might not be appropriate. > > So MI does not introduce a new risk here - and with the use a different > system ID for non-zero instances the dangers are certainly no greater > than in current deployments. > > >>>> we should not use subnet dependend fields (like MAC adresses) >>>> to control the versioning. >>> >>> >>> That isn't what we are doing. We use a different MAC address to > insure >>> that legacy implementations won't see the PDUs they cannot correctly >>> process. The protocol behavior hasn't changed at all - but we do > need a >>> way to allow multiple instances to run on a LAN and be invisible to >>> legacy implementations. >> >> there is an underlying assumption that implementations actually parse >> the dest-MAC adress for sanitizing the PDU. if memory serves me > correct >> then iso10589 does not contain a sanity check rule that requires >> to check the destination-MAC adress against the configured Level. >> >> in addition i know of at least two widely deployed implementations > that >> do not do, or did not do this ;-) >> > > Your answer to a follow up question from me indicates that we agree > that > incoming multicast PDUs pass through a lower level address filter > before > being delivered to IS-IS code. Therefore, the use of a new multicast > destination address will prevent legacy implementations from ever > seeing > an IS-IS PDU associated with a non-zero IID which is sent on a LAN. > > Your concern seems to be that in order to support MI extensions, some > implementations might have to modify hard coded filter logic which > might > be part of the kernel code. So this isn't an interoperability concern, > but rather a concern on your part that the MI implementation cost in > some cases could be higher than you would like. > > I invite other folks on the list to indicate whether this is a > significant concern. > >>>> since this is a essentially a redefinition of >>>> all known TLVs [which are from now on now keyed by the > instance-id] >>>> have you thought about using a different PDU version in the IS-IS >>>> common header ? >>>> >>>> suggestion: >>>> pdu-version 1 would be used for topology 0 [fully downwards >>>> compatible] and >>>> pdu-version 2 would be used for the per-instance-keyed >>>> topologies. >>>> >>>> all PDU type and TLV allocations stay as-is. >>>> >>>> that way you rule out any subnet specific dependencies and any > node >>>> that does not understand pdu-version 2 will ignore it anyway, > which >> is >>>> IMO a cleaner transition tool. >> >>> One of the wonderful things about IS-IS is that it has survived for > a >>> long time now and has been extended in many ways without need for a > new >>> protocol version. Such robustness is to be respected and not > discarded >>> lightly. Spinning a new version is a major step and one which the >>> community has thus far consciously avoided - with good reason I > think. >>> I see nothing in the proposal which suggests this is a desirable >>> approach, let alone necessary. But, I'll keep listening... >> >> TLVs are fine for doing incremental changes - but what you are > suggesting >> here is to change the semantics of every TLV ever defined (which is to >> be keyed by the instance-id) - if you want to do that in a clean way >> then you need IMO redefine all TLVs (undesirable) or bump the pdu > version >> field. - > > I stand by my previous comments regarding a new protocol version. > > Spinning a new protocol version quite rightly demands a higher set of > requirements than is generally applied to releasing a new version of a > software implementation. Given that this would be the first new version > in the history of the IS-IS protocol, it is reasonable to assume that > before taking such a step we would solicit requests for other changes > which might be incorporated at the same time. (I am sure many of us > have > a few things which we might like to see...) Based on the experience of > other protocols, I am guessing a few years from now we might have > reached agreement. Of course, noting that in this case the base spec is > owned by ISO (not IETF), it might take a bit longer. :-) > > It is legitimate to debate whether MI can be supported in an > interoperable way in the current protocol version. If the collective > wisdom of the WG is "no", then I think MI gets thrown onto the pile of > things that shouldn't be done now. > >> >> >>>> finally a question: how would i link nodes between different >>>> topologies if i wanted to do so ? >> >>> This sounds like a trick question. :-) >> >> oh it isn't - i just wanted to check if there is a way to keep > seperate >> topologies and still have them connected on a choke point. >> >> --- >> >> another question which i don't really understand: >> >> what problem does MI solve that cannot be solved using MT ? >> (apart from the 12-Bit vs. 16-Bit Topology/Instance space >> difference). >> > > MI solves the same problem as MT, but it allows for a greater degree of > fault isolation. This has been a significant concern for some in the > community. YMMV yes, this is the first motivation: having a router with different and isolated routing instances but sharing one or more interfaces. Today, MT doesn't allow this since everything is in the same LSP/LSDB/Flooding. This of course doesn't mean MI should be a replacement for MT... it's just an answer to a specific requirement. s. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jul 11 14:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0McQ-0002p9-6R; Tue, 11 Jul 2006 14:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0McO-0002p4-Gd for isis-wg@ietf.org; Tue, 11 Jul 2006 14:05:56 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0McO-0006Gc-0J for isis-wg@ietf.org; Tue, 11 Jul 2006 14:05:56 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BI5rr10356; Tue, 11 Jul 2006 20:05:53 +0200 (CEST) Received: from [132.219.24.126] ([10.58.48.57]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BI5oC03252; Tue, 11 Jul 2006 20:05:51 +0200 (CEST) In-Reply-To: <20060711155526.GA7543@juniper.net> References: <20060711155526.GA7543@juniper.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2d1beef9700b9301234dd7931dc8a64b@cisco.com> Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Tue, 11 Jul 2006 19:21:59 +0200 To: Hannes Gredler X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: "Les Ginsberg \(ginsberg\)" , isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org On Jul 11, 2006, at 5:55 PM, Hannes Gredler wrote: > hi les, > > tx for your responses - see answers/comments inline. > > On Tue, Jul 04, 2006 at 04:56:05PM -0700, Les Ginsberg (ginsberg) > wrote: > [ ... ] > | By way of preface, assume that an MI-capable router will use a > different > | system ID for non-zero IID instances than it does for the instance > | associated with IID #0. We don't state this in the draft, but it is > not > | prohibited either. In consideration of the points you raise, it is > | probably a good practice - and a future version of the draft will > | discuss this. > > tx for adding this - adding an applicability note [read: virtual > routers sharing a interface] would make obvious what this draft > is about and confine MI usage vs. MT usage. > > | So MI does not introduce a new risk here - and with the use a > different > | system ID for non-zero instances the dangers are certainly no greater > | than in current deployments. > > i have to disagree - > today a neighbor-id change is treated as a reconfig event i.e. the > existing > adjacency is torn down and a new adjacency is kickstarted for the > new-sysid. > a MI router interfacing to a non-MI router will hence cause constant > adjacency > flaps. the draft explicitly says that a MI-router not seeing the appropriate IID in received hello packets will not form any adjacency. No bouncing. LEs proposal looks good to me as using different SysIDs fix the misconfig issue you raised. > that is not my definition of smooth downwards compatability. > you should find a way for a MI draft such that MI PDUs hitting a non-MI > router are silently ignored. > > | Your answer to a follow up question from me indicates that we agree > that > | incoming multicast PDUs pass through a lower level address filter > before > | being delivered to IS-IS code. Therefore, the use of a new multicast > | destination address will prevent legacy implementations from ever > seeing > | an IS-IS PDU associated with a non-zero IID which is sent on a LAN. > > i was just raising concerns that implementations may not do this. > [in fact i have seen some implmentations that even were relying on > BPF filters [in lack of proper kernel support]]. i agree that kernels > *should* be doing this, but i have concerns that everybody *does* it. > > | Your concern seems to be that in order to support MI extensions, some > | implementations might have to modify hard coded filter logic which > might > | be part of the kernel code. So this isn't an interoperability > concern, > | but rather a concern on your part that the MI implementation cost in > | some cases could be higher than you would like. > > we all want to standardize _simple_ protocols that are easy to > implement > and hence proper interoperate. if you go down suggesting protocol > extensions (in fact protocol redefinitions) that are non-trivial > to implement then you are creating in fact entrance barriers for folks > who don't have the power to change routing *and* kernel code and > rely on 3rd parties to do this. my employer is in the lucky position > to be in control of the ISO kernel stack and able to make the required > changes, my concern is for the folks that don't have this freedom > of choice. > > | [ ... ] > | Spinning a new protocol version quite rightly demands a higher set of > | requirements than is generally applied to releasing a new version of > a > | software implementation. Given that this would be the first new > version > | in the history of the IS-IS protocol, it is reasonable to assume that > | before taking such a step we would solicit requests for other changes > | which might be incorporated at the same time. (I am sure many of us > have > | a few things which we might like to see...) Based on the experience > of > | other protocols, I am guessing a few years from now we might have > | reached agreement. Of course, noting that in this case the base spec > is > | owned by ISO (not IETF), it might take a bit longer. :-) > > well i guess this WG has a nice track record of not caring too much > about > "ownership" questions. furthermore i do think that MI does qualify > "a higher set of requirements" because it is re-defining the gross > semantics > of the protocol [=key each and every TLV by the MI-ID]. > > | [ ... ] > | It is legitimate to debate whether MI can be supported in an > | interoperable way in the current protocol version. If the collective > | wisdom of the WG is "no", then I think MI gets thrown onto the pile > of > | things that shouldn't be done now. > > don't get me wrong - i do sense customer on our end asking for virtual > routers being able to share interfaces as well. > i just want to make the deployment as smooth as possible > and avoiding hickups of all kind. > > the draft as it is today with its assumptions that everybody would be > able to filter on MAC adresses plus the kludge on p2p interfaces does > not warrant smooth downwards compatibility with non-MI routers. > > IMO there are two wyas to fix this: > > 1. define a new set of TLVs for MI usage, similar to the work being > done > for MT (MI-IS_REACH, MI-IP_REACH) re-inventing the whole set of TLVs looks a bit overkilling to me. s. > > 2. leave it as is wrt new TLV definition and find a dead-sure way of > interoperating with non-MI routers.(bumping the pdu-version field > seems to be the only drastic-enough measure to warrant that) > > i am happy with both solution paths (have a slight favour for option > #1) > as it would be in-line with the incremental nature of IS-IS protocol > extensions so far ... > > i also want to encourage other folks to speak-up and hear their > opinions. > > tx, > > /hannes > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jul 11 15:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ney-0002tD-Oh; Tue, 11 Jul 2006 15:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ney-0002t8-0j for isis-wg@ietf.org; Tue, 11 Jul 2006 15:12:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0New-0006j6-NZ for isis-wg@ietf.org; Tue, 11 Jul 2006 15:12:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jul 2006 15:12:26 -0400 X-IronPort-AV: i="4.06,230,1149480000"; d="scan'208"; a="92379444:sNHT4115991804" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BJCPPp004042; Tue, 11 Jul 2006 15:12:25 -0400 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6BJCPLY001012; Tue, 11 Jul 2006 12:12:25 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 12:12:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Tue, 11 Jul 2006 12:12:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Thread-Index: AcalHBghfTU+OmemQI6x9rn09Y2EIAAAHu7Q From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" , "Stefano Previdi \(sprevidi\)" X-OriginalArrivalTime: 11 Jul 2006 19:12:25.0245 (UTC) FILETIME=[F19694D0:01C6A51D] DKIM-Signature: a=rsa-sha1; q=dns; l=2526; t=1152645145; x=1153509145; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=22Les=20Ginsberg=20\(ginsberg\)=22=20 |Subject:RE=3A=20[Isis-wg]=20Update=20to=20Multi-instance=20Multi-Topology=20Draf t=20available |To:=22Hannes=20Gredler=22=20, =0A=20=20=20=20=20=20=20=2 0=22Stefano=20Previdi=20\(sprevidi\)=22=20; X=v=3Dcisco.com=3B=20h=3DznkOvryiKj28s9WfTD24XS+M1zg=3D; b=NAl8SkXx/wkO/FoLof7q/aoIS/TGruboCOtgJ0BD8PDMKcP4hFzYlVbhb6pug2K3rGc4xPo4 Exdzqul3DQGqBIfppmizmSI7kmjDs66VEMU+BXAIzz8gPqkYiiGwYCVV; Authentication-Results: rtp-dkim-1.cisco.com; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Tuesday, July 11, 2006 11:59 AM > To: Stefano Previdi (sprevidi) > Cc: isis mailing list; Les Ginsberg (ginsberg) > Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft > available >=20 > On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi wrote: > [ ... ] > | the draft explicitly says that a MI-router not seeing > | the appropriate IID in received hello packets will not > | form any adjacency. No bouncing. >=20 > stefano, >=20 > sorry, perhaps i was unclear what concerns me - > let me illustrate this by an example: >=20 > lets assume we have a MI router talking to a non-MI > router over a p2p interface. the MI router wants to > establish adjacencies for instances {0,1}. now the > non-MI router gets constantly confused by the two different > sysids and constantly is bouncing the instance 0 adjacency. > (in fact it cannot proper distinguish between the two instances) Please reread Section 3.4.2 of the draft. We have taken pains to prevent such behavior. I agree than any proposal that introduced the possibility of adjacency flapping is not acceptable - we have not done so. >=20 > | Les' proposal looks good to me as using different SysIDs > | fix the misconfig issue you raised. >=20 > the draft would need a safety belt way such that > non-0 instance PDUs are silently ignored by non-MI > implementations. dealing with misconfigs at the level > of adjacency FSM is already too late and one instance > may impact the other ... On P2P we make sure we do not send non-zero PDUs to a legacy system. Om LANs we use the different mcast addresses so legacy routers do not see the non-zero PDUs. For the corner case on P2P when for a brief period (due to APS switchover or some other event which changes the wiring on the fly) we require different system IDs for the non-zero instance to make sure any non-zero LSP which might be "leaked" into a legacy router in such a case is not used for forwarding. Note that in such a case as soon as the MI capable router receives a legacy IIH from the neighbor it will both tear down any existing adjacency on that interface AND subsequently only send instance zero PDUS on that interface - so the window during which a non-zero LSP might be sent is brief - and because of the different system ID it does not affect routing/forwarding in the instance 0 topology. Les >=20 > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jul 11 15:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NjH-0003Hh-V7; Tue, 11 Jul 2006 15:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NjG-0003HD-NQ for isis-wg@ietf.org; Tue, 11 Jul 2006 15:17:06 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NjE-0006qV-98 for isis-wg@ietf.org; Tue, 11 Jul 2006 15:17:06 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BJH1F14505; Tue, 11 Jul 2006 21:17:01 +0200 (CEST) Received: from [132.219.24.126] ([10.58.48.57]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BJH0C10631; Tue, 11 Jul 2006 21:17:01 +0200 (CEST) In-Reply-To: <20060711185850.GA8401@juniper.net> References: <20060711155526.GA7543@juniper.net> <2d1beef9700b9301234dd7931dc8a64b@cisco.com> <20060711185850.GA8401@juniper.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2c46cbc1bdc7295dcf0024a32b081748@cisco.com> Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Tue, 11 Jul 2006 21:17:00 +0200 To: Hannes Gredler X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Les Ginsberg \(ginsberg\)" , isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes, my concern is that a misconfiguration should not cause permanent/long loops/blackholes and Les proposal ensure this. A misconfigured network having adj bouncing is something we could expect... even if I don't think it's the case in mi-isis draft (as Les explained). Similar issue happens when you configure the same SysID to different routers (LSP bouncing). Mistakes don't come for free... s. On Jul 11, 2006, at 8:58 PM, Hannes Gredler wrote: > On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi wrote: > [ ... ] > | the draft explicitly says that a MI-router not seeing > | the appropriate IID in received hello packets will not > | form any adjacency. No bouncing. > > stefano, > > sorry, perhaps i was unclear what concerns me - > let me illustrate this by an example: > > lets assume we have a MI router talking to a non-MI > router over a p2p interface. the MI router wants to > establish adjacencies for instances {0,1}. now the > non-MI router gets constantly confused by the two different > sysids and constantly is bouncing the instance 0 adjacency. > (in fact it cannot proper distinguish between the two instances) > > | Les' proposal looks good to me as using different SysIDs > | fix the misconfig issue you raised. > > the draft would need a safety belt way such that > non-0 instance PDUs are silently ignored by non-MI > implementations. dealing with misconfigs at the level > of adjacency FSM is already too late and one instance > may impact the other ... > > /hannes > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From baisusannar@0451.com Tue Jul 11 18:34:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Qoi-0000JZ-II for isis-archive@lists.ietf.org; Tue, 11 Jul 2006 18:34:56 -0400 Received: from 20150012086.user.veloxzone.com.br ([201.50.12.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Qoe-00073x-SO for isis-archive@lists.ietf.org; Tue, 11 Jul 2006 18:34:56 -0400 Date: Tue, 11 Jul 2006 22:34:54 +0180 From: "Sidney Luna" X-Mailer: The Bat! (v2.00.5) Business Reply-To: "Sidney Luna" X-Priority: 3 (Normal) Message-ID: <44349473.20060711223454@0451.com> To: isis-archive@lists.ietf.org Subject: DRR MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 INSTITUTE FOR EXTRATERRESTRIAL CULTURES special and gifted and divine? No more than you are, no more than I am. jump, he says. It was clear how to get to the hillock. And then we'd stay will find, even in the most brutalized of translations, a strength and From isis-wg-bounces@ietf.org Wed Jul 12 01:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0XQ7-00023v-8q; Wed, 12 Jul 2006 01:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0XQ5-00023Z-N1 for isis-wg@ietf.org; Wed, 12 Jul 2006 01:37:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Wkt-00064r-Vy for isis-wg@ietf.org; Wed, 12 Jul 2006 00:55:24 -0400 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0WZv-00045n-Cy for isis-wg@ietf.org; Wed, 12 Jul 2006 00:44:04 -0400 Received: from [128.251.10.71] ([128.251.10.71]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k6C4i1Ug004993 for ; Tue, 11 Jul 2006 23:44:01 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: isis-wg@ietf.org Message-Id: <90929604-29DD-4D7A-8ACE-58AC5F086643@alcatel.com> Content-Type: multipart/mixed; boundary=Apple-Mail-1-426063650 From: Andrew Lange Date: Tue, 11 Jul 2006 21:43:59 -0700 X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: -2.6 (--) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Subject: [Isis-wg] IETF66 WG Meeting Minutes X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org --Apple-Mail-1-426063650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi All, These are the minutes from today's meeting. Please take a look and let me know if anything needs correction. Else, the chairs will post them as is. Thanks! Andrew --Apple-Mail-1-426063650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=isis-wg.txt Content-Disposition: attachment; filename=isis-wg.txt Meeting Notes ISIS WG 2006-07-11 Document Status: - Docs progressing - Recharter in progress - Still operating under the old rules until things officially change. - v6 standardization process a bit held up because of a comment from the IESG that it needs more than a ref to the ISIS spec. WG chairs are going to push back on this, since this is deployed and interoperable. Stefano Previdi draft-previdi-isis-mi-mt-01.txt ISIS Extension, new TLV, used to identify the instance of ISIS the packet belongs to. The idea is to have multiple instances of isis with full separation. True ships in the night. Dino's suggestion from the last meeting: where you have MI and non-MI capable addresses, to use a different set of MAC's for multicast. This was documented in the draft. Hannes suggestion: Work on PDU version number. This is practically difficult since the IETF does not "own" the ISIS spec. Some discussion on the draft's solution to this interop issue between MI and non-MI routers. Alternate approaches were investigated. IID TLV seems more straightforward to implemetn and support. No major interop issues here. Next draft will incorporate the results of this. Chris: We need to do some more due dilligence on the assumption of interop. For example an interop report. The reason is we're counting on old implementations working this way. Stefano: Okay... Unidentified Speaker: Is this a WG item?? Dave: This is on the recharter list. Unidentified Speaker: Do we have to wait? Dave: We're treating this as if it were a WG item. Mohan Nanduri: This is a good thing for operators. ------------------------------------------------------------------ Russ White: HMAC-SHA Crypto Authenticaiton Draft. No sequence number, so vulnerable to replay. Slightly less vulnerable - wrong packets are silently discarded. - works over l2 ... All we're doing is updating from HMAC-MD5 to a newer, more secure algorithm. HMAC-MD5: although no published attacks, suspected to be vulnerable. New Proposal: TLV 10, CRYPTO_AUTH - value 2, to add a new, expandable value for example: SHA-1, SHA-256, etc. Allows easy extension with new auth algorithms. Allows for KEY-ID, which eases troubleshooting. Would like to make it a WG item. Dave: Let's take a poll. Room: NO OBJECTIONS to making the draft a WG doc. Dave: We'll take it up as part of the recharter. Dave: What's happening in OSPF? Acee: We're working on OSPF over IPSec for a while. I'm convinced that there may be a good argument for a mechanism such as this, but we need to take this up with the group. Dave: We may have a generic keychain object draft soon, that we can leverage that for both OSPF and ISIS. This will probably be in the rtgwg. Dave: As a reminder to the group, we cannot do ISIS over IPsec, since it is not IP. ------------------------------------------------------------------ Les Ginsberg Simplified Extension of LSP Space for ISIS Max size on LSP's (256 * 1492). Not a practical limit for routing, but when you add a mess of non-routing info, and you add in multi-topology info, you could exceed the space. This was addressed in RFC 3786 a few years ago, saying you could have alias system id's, and have a new full set of info for each alias. To achieve the full flexibilty, you need to use mode 2 in 3786, which is not compatible with legacy routers. This is what we're trying to address in this draft. New proposal: - Utilizes multiple system ID's and Alias System ID TLV like RFC 3786. - Defines new TLV to carry non-routing info. - Define rules for considering non-routing info for the same object when multiple TLV's are required. Some discussion on the changes from the previous draft based on comments. In the extended LSP's you MUST have: - Neighbor to the originating system, having a metric of maxmetric-1 MT support for all topologieS) - Area Address(es) - same as the Originating System - OL, ATT, P bits MUST BE ZERO - MT TLV (299) listed as necessary based on leaf node information. Normal LSP's MUST HAVE: - neighbor to the virutual IS with a metric of 0 (MT support - for all topos) - one other requirement. Extended LSPs MUST NOT HAVE - No neighbors other than to the originating system - TLV's which MAY NOT have... Extended LSP's MAY HAVE (new info): - Leaf Information (avoid if possible - because it increases the set of LSP's and cause a new SPF) New TLV's - Alias TLV (24) - IS Neighbor Attibute (23) - identical to TLV 22 - MT IS NEighbor Attirbute (223) - identical to TLV 222 Neighbor attribute TLV's do NOT establish a neighbor relationship! IS Neighbor Attribute TLV's - may appear in any LSP - handling multiple TLV's wi came context (eg link) - if no conflicts: TLV's are additive - if conflicts - Normal LSP's - Extended LSP with lowest system-id Overcomes 255 byte limit. Example of how this would work: Router A: Original LSP, advertise Max BW : Extended LSP, advertise Max BW + GMPLS Link Protection If Max BW is the same, then add GMPLS Link Protection, if conflict (such as different Max BW values, use lowest system-id tiebreaker) Advantages of new proposal: - Single Operating Mode - No Change to handling of LSP's in SPF - Backwards compatible - TLV "overflow" (>255/object) is easily accomodated. Limits: - Requries support foe extended LSP's in support of non-routing info extensions in the future - Requries new TLV for TE info has to be supported. Why? Existence of RFC 3786 may lead to deployments Alternative Solution will then be more costly/difficult. Dave: At last IETF, a poll indicated 0 implementations or deployments Les: Did do a MList poll - got one response, but only 3786 mode 1, not mode 2 so it is is compatable. ------------------------------------------------------------------ Dave Ward Recharter Items GMPLS extensions from info to proposed standard ISIS and BFD MI ISIS ISIS TE for v6 ISIS for App Server ISSI for L2 routing and discovery ISIS for IP FRR Sub-TLV for ISIS Link Attribute TLV Split LSP space into routing and non-routing info. --Apple-Mail-1-426063650 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --Apple-Mail-1-426063650-- From 14urs17em@mail.ru Wed Jul 12 09:54:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fAu-0002NA-K3; Wed, 12 Jul 2006 09:54:48 -0400 Received: from [200.68.70.6] (helo=customer79-6.iplannetworks.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fAr-0005yP-8N; Wed, 12 Jul 2006 09:54:48 -0400 Message-ID: <662161c80604tbjkm9bx7u3cr64sbysnhu5aos5f237g@mxs.mail.ru> Date: Wed, 12 Jul 2006 08:56:14 -0060 From: "Tracy Mcfadden" To: isis-archive@lists.ietf.org Subject: 3VE MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.8 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 cultures. On the commission my colleagues and I represent the inter national smooth, easy entry." "No one with a pass has ever gone to the garage before. They haven't Jonathan was not alert to listen. It's pretty, he thought. The moon From isis-wg-bounces@ietf.org Wed Jul 12 11:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0h2O-0005yZ-7C; Wed, 12 Jul 2006 11:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0h2M-0005yU-Gj for isis-wg@ietf.org; Wed, 12 Jul 2006 11:54:06 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0h2L-0003V4-2o for isis-wg@ietf.org; Wed, 12 Jul 2006 11:54:06 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6CFs0g01749; Wed, 12 Jul 2006 17:54:00 +0200 (CEST) Received: from [132.219.24.126] ([10.58.48.52]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6CFrwC25676; Wed, 12 Jul 2006 17:53:58 +0200 (CEST) In-Reply-To: <20060711215509.GB9020@juniper.net> References: <20060711155526.GA7543@juniper.net> <2d1beef9700b9301234dd7931dc8a64b@cisco.com> <20060711215509.GB9020@juniper.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Wed, 12 Jul 2006 17:53:56 +0200 To: Hannes Gredler X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Les Ginsberg \(ginsberg\)" , isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes, On Jul 11, 2006, at 11:55 PM, Hannes Gredler wrote: > On Tue, Jul 11, 2006 at 07:21:59PM +0200, stefano previdi wrote: > | > | On Jul 11, 2006, at 5:55 PM, Hannes Gredler wrote: > [ ... ] > | >1. define a new set of TLVs for MI usage, similar to the work being > | >done > | > for MT (MI-IS_REACH, MI-IP_REACH) > | > | re-inventing the whole set of TLVs looks a bit overkilling > | to me. > > no shortcuts here ;-) - i do sense from your statement above > that you admit that MI *does* redefine the interpretation of all ever > defined TLVs so far ... hmmm don't you sense that I believe mi-isis solves a clear and simple problem in a simple way with minimal protocol extension that do not require massive ietf/itu negotiation ? > and that sounds like a perfect > application for bumping the pdu-version field to flag that > the TLVs contained in a PDU would need non-default treatment. I'm afraid if you go that path you will collect many other requirements and good reasons to incorporate other changes... I'm not sure it's a good idea for this specific case. Again, we are fixing a simple problem with a simple solution... > i don't get why you are resistant to use the pdu-version > field for this purpose [i still have not get a sound technical > explanation why *not* to use it] utilizing the pdu-version field > would fix a bunch of real-world misconfigs issues in a > non-disruptive way. but I believe the concern you reported has been addressed by the draft. s. > furthermore it would not make any assumptions > about underlying media-type nor ability of the kernel to > filter based on L2-mcast etc. > > /hannes > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Jul 16 07:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G24rb-0007RR-9T; Sun, 16 Jul 2006 07:32:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G24ra-0007RL-66 for isis-wg@ietf.org; Sun, 16 Jul 2006 07:32:42 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G24rY-0006it-Ud for isis-wg@ietf.org; Sun, 16 Jul 2006 07:32:42 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 16 Jul 2006 04:32:40 -0700 X-IronPort-AV: i="4.06,247,1149490800"; d="scan'208"; a="563097151:sNHT27126056" Received: from [172.26.200.26] ([172.26.200.26]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 04:32:38 -0700 Message-ID: <44BA23CD.9060305@juniper.net> Date: Sun, 16 Jul 2006 13:32:29 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefano previdi Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available References: <20060711155526.GA7543@juniper.net> <2d1beef9700b9301234dd7931dc8a64b@cisco.com> <20060711215509.GB9020@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2006 11:32:39.0451 (UTC) FILETIME=[8B3D36B0:01C6A8CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Les Ginsberg \(ginsberg\)" , isis mailing list X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org > hmmm don't you sense that I believe mi-isis solves a clear > and simple problem in a simple way with minimal protocol > extension that do not require massive ietf/itu negotiation ? no offense here ... it is just the nature of the change (one TLV affecting interpretation of all the others) that is unprecedented of IS-IS related protocol work so far, and that was raising red flags to me. i hope its just paranoia on my side and the potential unwanted MI fallout will eventually turn out to be "simple" fixable as well. /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Jul 16 08:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2622-0000mU-VL; Sun, 16 Jul 2006 08:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2622-0000mP-GV for isis-wg@ietf.org; Sun, 16 Jul 2006 08:47:34 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2621-000869-6y for isis-wg@ietf.org; Sun, 16 Jul 2006 08:47:34 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 16 Jul 2006 05:47:33 -0700 X-IronPort-AV: i="4.06,247,1149490800"; d="scan'208"; a="568354201:sNHT31816024" Received: from [172.26.200.26] ([172.26.200.26]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 05:47:29 -0700 Message-ID: <44BA3554.40003@juniper.net> Date: Sun, 16 Jul 2006 14:47:16 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft available References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2006 12:47:31.0862 (UTC) FILETIME=[00ECBB60:01C6A8D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: isis mailing list , "Stefano Previdi \(sprevidi\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org les, tx for your responses - see comments inline: Les Ginsberg (ginsberg) wrote: >>| Les' proposal looks good to me as using different SysIDs >>| fix the misconfig issue you raised. >> >>the draft would need a safety belt way such that >>non-0 instance PDUs are silently ignored by non-MI >>implementations. dealing with misconfigs at the level >>of adjacency FSM is already too late and one instance >>may impact the other ... > > > On P2P we make sure we do not send non-zero PDUs to a legacy system. > Om LANs we use the different mcast addresses so legacy routers do not > see the non-zero PDUs. > > For the corner case on P2P when for a brief period (due to APS > switchover or some other event which changes the wiring on the fly) we > require different system IDs for the non-zero instance to make sure any > non-zero LSP which might be "leaked" into a legacy router in such a case > is not used for forwarding. lets say we have massive flooding in instance #1 plus an APS event. then we end up getting a lot of instance #1 LSPs getting installed in instance zero LSDB, which (as you have pointed out correct) will be recognized as "disconnected" during SPF computation and not consume any forwarding state. however it will consume LSDB storage space and more worse cause confusion on the network operator side, as you have "zombie" LSPs from another instance that potentially may hang around for more than 18 hours. i know a lot of customers who still have heavy-APS deployments and that artifact of MI is not nice and IHMO should be avoided. > Note that in such a case as soon as the MI capable router receives a > legacy IIH from the neighbor it will both tear down any existing > adjacency on that interface AND subsequently only send instance zero > PDUS on that interface - so the window during which a non-zero LSP might > be sent is brief - and because of the different system ID it does not > affect routing/forwarding in the instance 0 topology. there is a window of opportunity [between an APS switchover and until the next regular hello is sent] that some LSPs may slip through and unless you choose a dead-sure way of encoding MI extensions for leagcy systems. ----- some comment also to the pdu-version 2 usage. - since its nearly the same set of people that drive IS-IS protocol evolution both in the ITU and IETF what is the practical hazzle of just adding a note like "because of the non-incremental nature of the MI extension we demand use of the IS-IS PDU version field codepoint 2" in the draft text and send a note to the ITU liason ? - allocating two well-known functional MAC adresses requires a level of coordination between two standard-bodies as well. /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Jul 16 19:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G8c-0001nZ-B2; Sun, 16 Jul 2006 19:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G8b-0001nS-9G for isis-wg@ietf.org; Sun, 16 Jul 2006 19:35:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2G8a-0006n1-MX for isis-wg@ietf.org; Sun, 16 Jul 2006 19:35:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2006 16:34:59 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6GNYxZE029898; Sun, 16 Jul 2006 16:34:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6GNYx2D028429; Sun, 16 Jul 2006 16:34:59 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 16:34:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Date: Sun, 16 Jul 2006 16:34:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Update to Multi-instance Multi-Topology Draft available Thread-Index: Acao1gIJJhWIAStvQauyXOYC+y6j3gAVu2GQ From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" X-OriginalArrivalTime: 16 Jul 2006 23:34:59.0460 (UTC) FILETIME=[73E5C440:01C6A930] DKIM-Signature: a=rsa-sha1; q=dns; l=5137; t=1153092899; x=1153956899; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=22Les=20Ginsberg=20\(ginsberg\)=22=20 |Subject:RE=3A=20[Isis-wg]=20Update=20to=20Multi-instance=20Multi-Topology=20Draf t=20available; X=v=3Dcisco.com=3B=20h=3DznkOvryiKj28s9WfTD24XS+M1zg=3D; b=QMs8WZvZHbzXGMjplzUG7VrkGzsvOTfNLehUtTTtUtC6VDtpFuWFsJIkok1GyCiO6zSnsUB5 FHTadc/zq2XQWLBFm3vCZMD+ZE4FWKN2phW8kUayZzAZwDnD9ShROzKH; Authentication-Results: sj-dkim-2.cisco.com; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: isis mailing list , "Stefano Previdi \(sprevidi\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Sunday, July 16, 2006 5:47 AM > To: Les Ginsberg (ginsberg) > Cc: Stefano Previdi (sprevidi); isis mailing list > Subject: Re: [Isis-wg] Update to Multi-instance Multi-Topology Draft > available >=20 > les, >=20 > tx for your responses - see comments inline: >=20 > Les Ginsberg (ginsberg) wrote: > >>| Les' proposal looks good to me as using different SysIDs > >>| fix the misconfig issue you raised. > >> > >>the draft would need a safety belt way such that > >>non-0 instance PDUs are silently ignored by non-MI > >>implementations. dealing with misconfigs at the level > >>of adjacency FSM is already too late and one instance > >>may impact the other ... > > > > > > On P2P we make sure we do not send non-zero PDUs to a legacy system. > > Om LANs we use the different mcast addresses so legacy routers do not > > see the non-zero PDUs. > > > > For the corner case on P2P when for a brief period (due to APS > > switchover or some other event which changes the wiring on the fly) we > > require different system IDs for the non-zero instance to make sure any > > non-zero LSP which might be "leaked" into a legacy router in such a case > > is not used for forwarding. >=20 > lets say we have massive flooding in instance #1 plus an APS event. > then we end up getting a lot of instance #1 LSPs getting installed > in instance zero LSDB, which (as you have pointed out correct) > will be recognized as "disconnected" during SPF computation > and not consume any forwarding state. however it will consume LSDB storage > space and more worse cause confusion on the network operator side, > as you have "zombie" LSPs from another instance that potentially > may hang around for more than 18 hours. >=20 In order for "massive flooding" to occur, we would have to have the following set of circumstances: a)Router MI-1 has just formed an adjacency with router MI-2 (which has just started) on circuit MI-1/1 and is in the process of dumping its Instance #1 LSDB to MI-2. NOTE: Alternatively, we could hypothesize a massive network disruption coincidental with Step c below. =20 b)Router L (a legacy router) has an adjacency with some router (identity unimportant) on circuit L/1. c)Early in the process of the dump mentioned in "a", an APS event occurs which causes circuits MI-1/1 and L/1 to be connected. =20 d)A number of seconds remain before either MI-1 or L will transmit an IIH. If all of these circumstances occur, then yes - it is possible for a significant number of Instance #1 LSPs to be added to the LSDB in Router L - though we both agree that they will be seen as orphans and will not affect routing/forwarding. This is still undesirable of course - but there are the following points to consider: 1)Orphaned LSPs occur in the LSDB in today's world - for example, whenever a router is removed from the network, it is highly likely that its old LSPs remain in the network until they age out. In cases of orderly shutdown, it is possible for a router to purge its LSPs before "departing", but as a practical matter this often does not occur - and isn't possible in cases of unexpected failure. 2)The length of the "window of opportunity" above can be shortened through the use of fast failure detection mechanisms (e.g. BFD) 3)The undesirable consumption of LSDB space can be prevented by the use of authentication - where the password for Instance #0 is different than that for non-zero instances. > i know a lot of customers who still have heavy-APS deployments and that > artifact of MI is not nice and IHMO should be avoided. >=20 > > Note that in such a case as soon as the MI capable router receives a > > legacy IIH from the neighbor it will both tear down any existing > > adjacency on that interface AND subsequently only send instance zero > > PDUS on that interface - so the window during which a non-zero LSP might > > be sent is brief - and because of the different system ID it does not > > affect routing/forwarding in the instance 0 topology. >=20 > there is a window of opportunity [between an APS switchover and until the > next regular hello is sent] that some LSPs may slip through and unless > you choose a dead-sure way of encoding MI extensions for leagcy systems. >=20 > ----- >=20 > some comment also to the pdu-version 2 usage. - since its nearly the same > set of people that drive IS-IS protocol evolution both in the ITU and IETF > what is the practical hazzle of just adding a note like "because of the > non-incremental > nature of the MI extension we demand use of the IS-IS PDU version field > codepoint 2" > in the draft text and send a note to the ITU liason ? - >=20 I think our opposing positions on this are clear - so I will not repeat myself - except to once again invite others to respond. Les > allocating two well-known functional MAC adresses requires a level of > coordination > between two standard-bodies as well. >=20 > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jul 17 15:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Z6Y-0004en-5z; Mon, 17 Jul 2006 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Z6S-0004cu-JE; Mon, 17 Jul 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Z6Q-00007Z-3F; Mon, 17 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6HJo11u023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G2Z6P-0007Yo-KO; Mon, 17 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 17 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-sha-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org --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 HMAC SHA Cryptographic Authentication Author(s) : M. Bhatia, et al. Filename : draft-ietf-isis-hmac-sha-00.txt Pages : 9 Date : 2006-7-17 This document proposes an extension to IS-IS to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification and RFC 3567. Although this document has been written specifically for using MAC construct along with the SHA family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-sha-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-sha-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-hmac-sha-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: <2006-7-17125742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-sha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-sha-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-17125742.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From arisa@072.com Thu Jul 20 04:23:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ToZ-0006Ds-15; Thu, 20 Jul 2006 04:23:23 -0400 Received: from [220.72.104.83] (helo=winxp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ToX-0007C3-8u; Thu, 20 Jul 2006 04:23:23 -0400 From: "Mitzi Calloway" To: Subject: Your future, one-chambered Date: Thu, 20 Jul 2006 08:23:23 -0540 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_006A_01C6AC21.341CD1C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C6AC21.341CD1C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006B_01C6AC21.341CD1C0" ------=_NextPart_001_006B_01C6AC21.341CD1C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable paper-slitting odd-thinking open-mindedness mid-mouth Morocco gum park flower name plate narrow-rimmed night fire outside broker night-singing narrow-streeted orb weaver night shift monk parrot N-shaped paddle hole nerve cavity pampas fox Parcel-latin=20 paving tile no-being nook-shotten parsley fern old-school oil pan off-thrown mildew-proof one-roomed one-nerved=20 mignonette lace noisette brown ------=_NextPart_001_006B_01C6AC21.341CD1C0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""

paper-slitting odd-thinking open-mindedness mid-mouth Morocco=20 gum
park flower name plate narrow-rimmed night fire outside broker
night-singing narrow-streeted orb weaver night shift
monk parrot N-shaped paddle hole nerve cavity pampas fox Parcel-latin=20 paving tile
no-being nook-shotten parsley fern
old-school oil pan off-thrown mildew-proof one-roomed one-nerved=20 mignonette lace noisette brown
------=_NextPart_001_006B_01C6AC21.341CD1C0-- ------=_NextPart_000_006A_01C6AC21.341CD1C0 Content-Type: image/png; name="4YWTWX52.PNG" Content-Transfer-Encoding: base64 Content-ID: <006901c6abd5$c43529c0$6c822ecf@J9SB2DC> iVBORw0KGgoAAAANSUhEUgAAAcEAAAGWAQMAAAA6/qrkAAAABlBMVEX///8AAABVwtN+AAAbaElE QVR4nO2cQW8bSXbHq4u0WJI4IVfxgRAaRqnMFVsKAcuCEeQgCBRnsMN1Djs7+QKyd4NIPpH0Zca5 lNrKqLqpYBRjDhyBMBq9gKzVDLAj7iWHgdCwN2quhIV28gmcxWIg7CFrOxePcsl73STVlCUPpQQY DOIHm2o1+6cuVj++939V1U3I/xtLKUJ0QlhBEsoJiRNCM/j67Ubhv4D/BUJi8wF5ifVJZr7yeNXP PFcN+uhG9UD8nqnqQV8k2+KZmqEKyqWbW7Ws2GSqlu2P/Oxp/GicFdQONbaOgEypo/5ay7YINcdY 4Z84kGZwTrNvUpiGKrXJjYCU/ZC65enVnH79sU5zonp1VLFGNdbPOb8LS7FnH5MiJZqHv4EbcbNP kn1ilWQxYMBi5yFd25AvdnWauLG9L2I5cT7ybSHg6rTy4EZu32RqtvZnUhQZIK1DdMC+ySFhTwIZ B9I2NuhC/+SgsCfITWitsbW3sA5knxx+zheGnM7pmi+2N02au9z3OSMm+/tGn0r+zQXJN/bGLmSY kSjlGSZJkNT6t0uEIckY/g12HpI1KvujNMcWa3qZsG3vHKSr8huxQ1VfdRVhe7x/MlW3DiEgKKXc ecLs87R2uWqEZCN9TtI1F8aBrCtHecw+R2uhhzahh/TFVqMsIa+d46REtX8K7TwUWrn981xuQMLM e95zhXZJnKdXosac81yJXvLogmRqw56/4DndC3/Oi5ONi16VN/bGvo+WIoSnJWhiD0srhRuZ4I2Z 42NOT1SQ/QIyLOdauBEeKL6VbFScmW0fSg4dyrHfthqQ1yo+5DVRZg3by8P29j7ZbslXSXdoPr1n uNRwoRzbwg2lDMhrQjG3xqdtw9zLyz3jVTI1e4+na1/Pxg6coyz57E/12IH65uvZ+YC0Cf/m44cm k/bkq+QQt3na1jhV3MyS9aFlqpg5xtNADiIpS+IMcpCvz4/YzKFwRFauD7m0xMwFyGtCDbjrUIMY 46YB5OrUk1d6aNFJWmEPXSXWv+FG5ZFeljNl0rhDeMUfXWpJ69+Sr5BnmNb+fzH7i9e/zWSBoQ9M dffIPv9whyydmxxqPN8n1Wtkbp98ta9TX5T7Js1iXtpZAq9beTcG3tM3+bDIkHxhgOvN0mtb832T bkgWkYQifTLdL/nWxk1wkZ/LLqm+nQnt0uj1lqz8gsy1iNUCB7rcdw+9sTf2fbRoXUaTUx8xiHg4 VpQgY5RochZ2a1IPRxrKPWS0Lrs0UqIYKzGvMYlBUwaFnhQhyXvIaF3G1ubMzF2fUPZ5tZX/2S7E a7a9f6MsuXWgf+UR4feQkbqMrRVMNghnU82aMT1GBZNsL7/FZMbOii1OrvZktGhdlvrymck+TElS co8YH6P8A8lqh5MfyLi1PPtLSYTRc85IXRac04Lwa7hmQCrJbDapJK2/wzcLJ8lIXRaQnxpJOtE0 mTMmRD0g61LcyTpbV4Fc7e2hbl0GPeTrCz7Tdj+vJnjZ1xc9ZrXEoqcPPtGtx6SaS/b0brcu6+xI n+z/YNcpg0en1WUnyaevUIEPSfJSkvkE/l0Swz80H4deuswRp8HYY/BHE+gkU14vLuEsbA3PFJfQ eA4N45ffC8hg7FHgIYFXcdmFBnStRpZqOmczIH2035Cl3+XHDjLb3mVrs7Htj9JhveIJO6d/wcRd /8ZcpLWCrMpnqyYfSA+BGMoSc7Ipsljk2wvmnrGhrZo2F+8bbmtAWCw6pkczREmpHnItfe9anV4D 0r36Ryy4j4yHdsolpYf3nwph7ChN3Er1kPGAdDlZs1rx4JyuiDMonOwfCpsJ9CcixD9wRTZ+wCZJ T2uR3ODswToTQNrQ2riCotT++3HbGKf5DZuIn25yxdYtI0omdK0ll1rr5URyMeihSuvzyhMsoS13 1PJHtf3RiqernK4StOxHBGjPpeXhTx7Z7kjUkjzNiToWDjiHZGe7TcZW4OXECGQcPqnOyQUsTmI/ FO9dhEzpMcPpWxv0nFPQzfpFyV8tv7wguWBe7JwuXXAvRMZ0ajQuRL6xN/Z9tKgeAoUAEQviyyG+ A6FrCmdkZznDNBc73Oklo3ooCHNAhskYfivhHk4MJOlbJ75RPXpIQJG/kNJJTbf8PCT5AoOkxm/t z1RBJA2pXg0W1UOpy1Dk1+OQ3VybN9e5KKQgqc2I/FrNkLE91XvSqB5izB6fVUAq11pxLSmeMXb/ KRfG2tEACDM133vOqB5i9hgPSVVyVUEUGDMJH2utmRqS6ROtjeghaK1Tj7tArk+42NqAFOyByVaB 7G1tVA+lXOyhmE5UY3HXDXpIX/J4pbVaTTDoi94e6tVD8pXrTdp5LX3KG1E9dCp5nNdOGGPqSMzG grc1SQpQs8tAR3/rPDFjnwz/PWunWiCTskBCHX1qC7qWyC8wd2RT0Vy+sp8vS/1ZsvF8BTZ49Tf6 9r5+slci1qynXAGk0bTzTZCyhSGzoJpM8lpW7OVfkzgSIMJ3xDUVO3BuG+5LeaUw9LCg3A8kt6/N 3j90zk5z4LfMLRqKMj5iuFKKwqALpAIyy0Efn/1ZB906uFFA2kiOlwY3SsoFHR2Q7tnkgAs9dARk AnzFrXijU2z9uo86uprVl8Cxzu6hN/bGvoeWAqcnEHhIO5QFZXw8jFrp4HUWDiBYqQneM+4M2Y/i 4iGC4ZNi7AzIMFIGrxx3o/r/695zsob1WEDgqbakbTSqHpbxv0/pUN5v788ERRm3H+vbB5mqN3nL z1SPy3vm2kJA4Bk2pFVyaxzL+M24gPJ+L78WFGUzfydEK8tqfFIYqnZc3qdmA9K9xySksyOOZTyQ UN7bkHCxKONCiCWs1MTYR5Dsuucc4u8HpD0oldUweVDGx7EcQxKLMiTNLJJ8DpJdlxwEchwCz/qA tH7kmBzL+E0Q2hPNPWMkKMo4tNb8uQISWmsft5Y1xvxRCDx3iKzyRpVjGa9iOpT3261kUJTN2r6+ 9Au9ygWUttXcqxcWx2gwnXWSVlAXB9ePvt4jcFT6LzCdPe2XbF90EDOcMHn6MWeRsfkO+da5SHCX R/kyZLRUvjwEPnSOcwrqNBVktPi0GgIfOheZc+Yho8XFy/PNhQJpOGmGpDwnCe7iKMhocfecJNRl 404ZMloMp3+q5yDf2Bv7PlqCFCiEu3SZiLHHGJNAVrMEwdWxCaL9BkIiTg9pkJckpqvCQJcE7Y2B Mq3I9Ps/DKIZkEEoA1lOsxGSYForHAdCpj8bmKG5GUambTg0d6O8Aipbr/5V5gWXNKX/2pvZ9sRd P6/9843Khv78cXcQjQloLTXW0mTSUjJ2uKVksz4g7LwqjhFtmf6WpPe4GGRNYm/Zt2lRdMnBHSSv rXEy+fInkhpbL1dcpc2aBivCMe9cWSLp2tPJD5kA8khcefsPx+d0kFxIczKuDCQlCGriIHmbkKwA 0obmBKQpRJGOH5MlOqJtjhAybhurSFqgsh17gf3YITS7scRHgPzUcJG8PX6Tjnavij6VSJJckhNh taD2EJVddyGhVzb1KUG0J6PSS1re5QVfaKC4H0HWO5FlCuGP9Gk7T1jvSGNMnnLIqTt7RhrbGgdb oTSSOfXw0y2ijqR2jmVoWJc1Yu/qXwzc+Gq3ftdn/Y+mNaHSoZtmi05uTajBkyXx687pqqEd+quH ik5+dqg+TPVPQhYbcuimAHKLKYuxer8kZDEkx5EcVJ8abMHrk4QsdkmnuVGVENZuY8HXWb/kK3Za Ed+fPb0w+cbe2Bt7Y/8PLLXz339+zT/5Xbev175frf0uLIGrzzSKekhjoaTBDIoKOBinZgOEolRK 44IOvPssLWVIUlx9Fq6N09paKCDxODyE0XCxfock3bVbND+3f+PuLuihfGw/Ux7Wt/dnND//fDdf juvNXH6B6tUfQfE/c9e/UT2AMndmu9Ymp4v5rUEqWnRaSyqVdPfya9RoFsQ0VN57vFmnwjanFVsb ZHj3GRXp1mp4VipeGJMfUlA1QmNqns3aRpoyd+4PYj4lzEcO7K/BuwPpD1NbR9kMddNKdciiMWl1 yDSOOSMJej0dF+YmkrYpylraYpNmNn6S/FQEpKEU4zgsZLg3bwtorflLB1tbFJI9+NQA0qXuSIdM iLmWABkEeojg8g8dh4V8cf2RgB5a+pED+rqaE+VEEmR19aquvZu0Tln1Gdipu/sSg6eSp42Qx3nw aeF/UvNwsFE7UOA9xfDoZXAOXFE0RfWKB9WVHgw2Rkn0khEoygo4D/MJieMdZ9hCdJrLQJYGgqX7 XEQKgFS+/JZeBY9JpGlCf76SJ2MCSsAXPlnyxfbHmQoUZZ5eGBKK69sOr+BgY/ucOCw0LNBLNOUW VJPM4ZqKtw1523BbyzjMZxGo3YTy6N58xsbBxjYpXg7t3IPryb4kP3EKyiXmLL1GitfkXx4Kucy+ kbNLRDyjVz7gV2weP4p378OICznk2EKU2RoxOJAaxXMWDTLEkJQFKM3gnJRx+KjUjJAukOsCvAQc XZSUS+NI3jSIzTbksjKhtRzI+Agft+eFmVUdMhgWuoNektZ8/bovYn/EHprOEVwF+wSXxpShh1L/ +h/eqOXolSf6yTGki0/6n38eJcGegfec69aetrG6IiMXIsmmSqRj++e9BYVgwHsG3pN0z09SBt6j sZ1vP/KkxRl6LHPOT7KANC5ApnaeJdIQgc5PfheWmC3jjEWSrOhpoheCnAMhJijVM+053mDwYSz0 lnh3mIE56hL8MgIBYQq+h8ckCar+4xEL7RWSS9aATqLKfI/w5wf6V/sz5VT+rpdp5pjljd7yRWVX 3/bEz/bJtp+vHJDnXkgOzEjmFiAgqNU1kilkxVZ+TcWnBwnbM+BLPC4MnAzZ42IsKfeMJq6C5u1G cJlyChCEVsw1Ep/74+xnh2vzcfEhYbahak/FmBK3TGHJyTEm738tjuJdkjiSOXhOab4ktJjlW2wN sphFmFVS7xPBSyJdFKqApKkJ85iEHmJuCcglkfbEzZ87W+yBiruf8pCE1m5Aa20+OWZIkzXNrLzJ u1eFNabgi/afetrTr/9Ct1qr5ZhY8HS1oo95oxCNKr5ueZfLLbkEPfSEXPcucvX5tx7RJ1kI58uS xEt3dqCBM7QdgyQp+hkjAyCe0j3TJsGhIxo/ixyh4U4UT11yOF/2MYVhpGZf2j6p5vLPPXAacCO9 7VLgYbv68/1M5TGZ82e0/XD4LdlUJUxhQWTANR620SxyusenMYWFLsXWYkIU80oJUjDWSH4jIOF6 Bilsnn0Za63ZKXl0zZ2TV+4/BWfItF2KfUlFpmiwpT+Q54dp7dDtkCVMYengnDYjSyVRKAiTABlv uxQkKxEH0hSQ49KgecLWAokpDFs7+GA9IG/ycSR5x6WQFDcNZt8mxYUHdCFs7TCvvospDHtoYPVO gpRXxHVvdClIYW2Xgh7K6ddbeuURmXuU1DbXw9YSWriYVzAcXr6oQZjwCC57lQT1chAvtOBuoesk /LuohgunTLnBaTmSIL9wArZDQvDCicczybd0NaxribwFnrGi/0tN1w7057/Tf+0Tmsu/7eXLSla9 me3fQfi5UX03mqCHTNDRGmsq8AzlOqsuzdLipPtbJkFZa2QaNGmNp/cmZZFPDikZSbRDDxXbibWc Xx7i4h8PVM3ylbf/tGNByWC4GuEvlbR5uvYnJP8xJT+IkDi2DLlsy0DSUQ3yjigOOZbWJqWFpD2E pK2iQmRoYyEZkAvjQK4ph2Y3bgKJY9auxrn8CMgRIG/yyfUSiYxdsnWGPcR/ujkKeshqNbQno9db DeUnY74gHq94sspRR1/3xJ0cWYj2bu+g4ivrZF9zh9DTnt9ekRpn3yEElx+7GjymQEJn6l5yBi3Q ArndDVG3SHuFGunq9lBQa7z3z/KwscchCr2q3b8DjcoKzsbD9+gZFGWJ/Ff7enkAbxKqepntDf3u ruiGqG1fXPUJqYWfaNBVCmfjKXcLSXCd5mbehaonZrg1zvZuCyjZuiFqz3Ahu5DVdjTZkcFsfMyv F9jOfXQm5yXN0GvuEaQzwaFke9kJUZDLxgagtaF4Yo5cwtl4ypYLzFlCZ3IkjVPjshmQFr0sOyEK ctkYfG7lhK11oLU4yzHolpIBueBKEOQheVt8KgIyCFEm2xgzVjsk9BDOxifpQGNqWF9KcGuzUU7o NMeqRLce4RL9boha8kfLfpKoV8XThbTqBchE8BpU7+GOcB1IaLjEHl1FYhGWkr3R5HiWv5vIugdQ EiVP3pHP9H/38wqdZkbz8lWo6iEU+fgMEOrrtw707V1p7za+gPKNCXgXK8IOKT7jzcBp1gifrkFV D6HIwGeAgBuJrNibkLUJtwXlW+pyjTcjU+VMbOXA3TLUWNOe8iMD81r7GSApd2x59v4h5MUdibP6 zMy5tadR0nDr6DRrlHMTyUb7GSBM5+9wvEERvApn9ZlpuNXI53Q/m3AX0Gke0Hl+33BKEIrCZ4BA DZd1zEG5PgGkK9lle8KNPNojodu7LkOnSWoOr/ocglD7GSAJrMKWduWd8YaE8i3lVsfdSA8F1zId 2e4saIyfEpNOlG80EooCMlzQ+Den3oEfyQ7Hglq0UR7eS9K+ixU2poIA+MrCkIigbu95hQwHkNjJ JHgsqCfLw3plV1ScGcvL27uf4/2vrUZ1VxZ9HQq3xdqJxh8L6klIaihI59M2ONNE0w7ufx2ekG9D mkia9dUTtduxoJ58yWbv/0Ec8fQWFOOGAxu2Ub9nyBepHY1dUeoEeSyoJyXjJr1sdkgTyWXbkEXG NSbUyVBwLKj/GkgbyPkRIMFvYAOcZn0iII3xejv8RHqoI6gvl5le8VnFSf4U0ta4AxvWbuPOuCwm dNIaXfxf1G5n3A7Sh510KY4vXrgtcfhHtjfBxj7qufy4pszrJTXeJUlU9rxnnnAc2jmS4Jxr1Uc9 pLU+13bd6kGmgnEob63gKlhlkiD2QASCRKbfzo1qw/rv2yRrDhuoh0D9kAm3lmUK41BT4Uw6kkHs EWEig6pHS7qbbXJA3EvVQQ9RwwGxfBRn8yCJPoZkMztPyEuT3M4538jJI0hkh7PimhtriQ6pCZvF QdUASY1PzDhLg6+U+HsKvzJwzhEIQoVJE9MRHysJcKYOydx1JpCccOgikJDZ4E8A6SgPSRuciYek M1Yaj5AJcSeBekjbdbQNVY3pFYxDfMzXyx6xoAgBZ/IuVzGR6eWVUY3prxkP+r/zlTOtGCyp7wwm k6nHwceXHfH1hM3LML5wDSV3pEVF0kP+mAdkd/A6K3n7/jhOesgEebGbXxjWf92S2wek6ulzA3rV IxB1cL3HPqnEM2MrUJphmit/1PgCwlUHlW+L6XrSBBG9l4XqRcxRUeMEoo4FjpWXg3HGJZRm4GpN Zbkt0r09OSGLgiv2cCm47/keF//1mB+BD6jZJXQP8o8HjK+svURXA821IyFctUkWku7SIJI2nhOf KKUUD0kLzqnWJLoahCIHSNkmB+VNwevJjaVxIOV60FozRuqKW+iP5FMgrQcycDVlORLCVZsckNM5 vjA8Kj1pPSF3uD6X0KuULLb0ss+1FlmMQ/iG0gxcTVR2GxLCVc81Zb3a+RzPsmLfenf9aZAW3pFB MvP4j3RKfx48gSETyphi0CZ5oi0dknH8d0wG2oedJPkxmPm1n19IQexhPAH/xBdBZCLs81vgQC21 kNDhu/bCJ3d9fQ0Pi7QWdHQdVxYqThRnbiuITBCfRB5UiaozEx+UZkiLuQ4eJo9JK4VLEbWPFU8g KYPIBFWXYNLEmYgr1seyeE3eYo53kmQ4OUFKjLOADCJThBSqhMPWP2AOnFNrRUlD1OMQKRkfBHIj dJcpIA1pT0BrN9YNHLa2DHcNDovIBV35YiEGHx2KDVDTozKITPySqLQkOM1CYnTRx2Hrsh+ske25 Gfg0K5yx//jexfNa9B6PdrtvhVNmwW/t5zd0HgmCFiME4xOLDiG0N8dCvRz81n5+A5PHJPxRHj2c YNVhe0HBtZsvD+RBjFV8fH4DTvmEjwTx9Lt/qzezujYAvpWJPK9gENe/YsFFpxWdhoIZxQh6j2w/ EgR0yucmvGp0ethQkYvC3C1OsOAKJr6Iqv/sa3x+A5LhI0Gecnvzoc0zscfinsE+OEFiwUVFGcnl EQ09Zh3I8JEgBEjXno9rFEQSU9HWbl0NCi4hJJKuzfD5DXcmVtuPBCHQ2g3LgdaKdfgCRHvofREW XFChCvAk7KEWGdxdbT8SxNOrfzWqOOQ7qO31xcj1PI460fTWU/Czs30qtGhQe9pLnrEeDU7AOn4j sQncI+066iOyJKGYZ93DbsmeIIm7jp/7ESca72zTIH2p48P4MRlMsoKantvHJ1ZqNVE5ILeIvu1l oMMqpv7FChTznbnYfZ3L/F0vJINJVlDTxTw+PgbvLMuCD4s9CBDEZSZtwRVc7czF5k0up63Op8dJ 1nm288KYRVK53yyTq56oPWXzCfcD84r6WEJ6CudiNfWQS9ElcZI1zZyiwekCkJ/Id/CcNmFp9oky Ba5mU+25WFJye8g9Y0QlkdQ2N4A0szIk1eAndXO8paAk787FbiDZ7r9gkhV7qKUTEIQtVXlCKgQf 9FkeUIv+6HZQzLfnYlvrwfRZp+ePL3Lh9Mt98rBXd53lKGeRQavj3bc4Lnr1WNiCQjB8iDbAyHJP 2X8KiasZg32FaJ1Po7McbcuXE/r2Qd7alRVPb/LsbdggmWZO/693888SoyCuURU9zlQ+DmZkIzYN wmQvO21PyCEcnjauTkgLJzrc4mazQDZAXIMqsgVTyxRnZCMGRbuwlnntUH4or9h8CtJJzWP2tXrx V24hARoIfIvchvS0fKXQW5pB0S7UOxyCiCpAIWgAGUx0xIubosBcENdAjiApTpDTuBQ/66xDDc/H LScrJkJS3NwUpcGN91Bik6C1eN/ZVITEHrKe8MVduehBvBHVceghnOiYzompgXUQ16CKKhCfnuDt H1Gy1wpnvvMt9no36jWmXuREua13cSGs9lH3PR6OG3HcwiUfWo8Psk9qYlq1ySBSmRESLR0cH66q jpJDLpCgA6scpDSDMF02IZF9Hns3X+V5NZC3/JnbPrntzWyvBJIoStruJJCgbIc5g0TEoLoxmnQT yjHMbraxdtWQV3kaAhJKogi588KdrBNmc36PM5A+HyDp0E33iGN2q32dBt8QPK0+IiiJoud0b4+r gLQh3pWwoloPSHNe1Kl4X0uLHEFyKZBEx+Rb7gMgwVHnxTq2ltRNSGRILjnTC0CyB8IAEpd8oCQ6 Ji8JG64K9I2jg6CGHgL1M7jrQNQu8zxLiDE/Wc0RHKr2A0n0+mvcHb9rb/R//87T4BX8KdxojyZ+ 5/Y/gaZBsfY0eAUAAAAASUVORK5CYII= ------=_NextPart_000_006A_01C6AC21.341CD1C0-- From isis-wg-bounces@ietf.org Fri Jul 21 21:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46T1-0002QU-62; Fri, 21 Jul 2006 21:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46Sz-0002QP-UF for isis-wg@ietf.org; Fri, 21 Jul 2006 21:39:41 -0400 Received: from web25410.mail.ukl.yahoo.com ([217.146.176.228]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G46Sy-0006Db-6Y for isis-wg@ietf.org; Fri, 21 Jul 2006 21:39:41 -0400 Received: (qmail 3792 invoked by uid 60001); 22 Jul 2006 01:39:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=e+yI7izgcjktYvWghMBfRIWKralTzLNlEkUirvET5hf0h+syp2cY32YUOramxHnWpZdoIXiAV5bM2d9EPQcmiuvJswphMVxFSvkK7DGrGsaekNN/raHguSlPcPeTncCFigTxmBpZ0sBJ72NWJIuTXzIWIgdcEHDi7r30deZVFfo= ; Message-ID: <20060722013939.3790.qmail@web25410.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25410.mail.ukl.yahoo.com via HTTP; Sat, 22 Jul 2006 01:39:39 GMT Date: Sat, 22 Jul 2006 01:39:39 +0000 (GMT) From: Manav Bhatia To: isis MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Isis-wg] Cryptographic Algorithm Implementation Requirements for IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hi, This draft follows the ISIS HMAC SHA authentication draft that was presented in Montreal. This document lists down the various authentication schemes and algorithms that IS-IS can use to authenticate its PDUs. Further to ensure interop between different implementations, it specifies a set of MUST/SHOULD/MAY support auth schemes/algos to ensure that there is atleast 1 auth algo/scheme that all implementations support. This is basically an equivalent of RFC 4305 for IS-IS. The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Also, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms should not be included in the base IS-IS specification. This way it is only this document that needs to get updated, whenever there is a need to update the status of mandatory-to-implement authentication algorithms or if some authentication algorithms are deprecated/obsoleted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.txt Thanks, Manav > ----- Forwarded Message ---- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Sent: Saturday, July 22, 2006 1:20:01 AM > Subject: I-D ACTION:draft-bhatia-manral-crypto-req-isis-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Cryptographic Algorithm Implementation Requirements for IS-IS > Author(s) : M. Bhatia, V. Manral > Filename : draft-bhatia-manral-crypto-req-isis-00.txt > Pages : 7 > Date : 2006-7-21 > > IS-IS currently defines two different kinds of authentication > schemes: Clear Text password and HMAC-MD5. There has been recently a > new draft submitted that adds support for a generic cryptographic > authentication scheme, which can make use of different cryptographic > algorithms in order to authenticate the IS-IS PDUs. > > To ensure interoperability between disparate implementations, it is > imperative that we specify a set of mandatory-to-implement algorithms > to ensure that there is at least one algorithm that all > implementations will have available. > > This document defines the current set of mandatory-to-implement > algorithms to be used for the cryptographic authentication for IS-IS > as well as specifying the algorithms that should be implemented > because they may be promoted to mandatory at some future time. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jul 24 00:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4rrC-0003Ai-0g; Mon, 24 Jul 2006 00:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4rrA-0003Ad-SR for isis-wg@ietf.org; Mon, 24 Jul 2006 00:15:49 -0400 Received: from smtp008.mail.ukl.yahoo.com ([217.12.11.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4rr9-0001u5-4h for isis-wg@ietf.org; Mon, 24 Jul 2006 00:15:48 -0400 Received: (qmail 18117 invoked from network); 24 Jul 2006 04:15:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:In-Reply-To:X-MimeOLE:Thread-Index; b=YG3jDiKSK+MuIk6w8x5Szrjfk0yEjj9AsHkI1WkXkESTiCCcLBfmVaoveHfKNUsyub5ySTXXjZDTshluBiK8aDjxH5isB3wmZkqAfiRu/UK6EBcJEksa3W0+YWabmSTungx3hUzvo9ReShcqnj6BxJr2mBIcuF1IjUCWUtSi71Y= ; Received: from unknown (HELO pfloyd) (manav?bhatia06@202.144.106.188 with login) by smtp008.mail.ukl.yahoo.com with SMTP; 24 Jul 2006 04:15:35 -0000 From: "Manav Bhatia" To: "'Jack Kohn'" Subject: RE: [Isis-wg] Cryptographic Algorithm Implementation Requirements for IS-IS Date: Mon, 24 Jul 2006 09:45:18 +0530 Message-ID: <003901c6aed7$c7bad630$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acatu5SWeGwYNfdWQg6352jcYCdPCQBGq9mQ X-Spam-Score: 0.9 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Jack, These definitions have been used in RFCs (4305 and 4307), internet drafts and the community since quite some time and I don't think there should be any problem there. In cryptography, algorithms believed to be secure today may get broken any time tomorrow and we need to continuously deprecate such algorithms. Thus an algorithm marked as MUST may not always remain a MUST and it may need to be demoted if there are weaknesses found there. Hope this helps. Manav # -----Original Message----- # From: Jack Kohn [mailto:kohn.jack@gmail.com] # Sent: Saturday, July 22, 2006 11:51 PM # To: manav_bhatia06@yahoo.co.uk # Cc: isis-wg@ietf.org # Subject: RE: [Isis-wg] Cryptographic Algorithm Implementation # Requirements for IS-IS # # Manav, # # Would your definitions of new RFC 2119 language be acceptable to the # IESG? I personally dont have a huge problem with it, but I'm just # making sure that flies with the IESG (or the powers to be). # # Jack # # ----- Original Message ---- # From: Manav Bhatia # To: isis # Sent: Saturday, 22 July, 2006 7:09:39 AM # Subject: [Isis-wg] Cryptographic Algorithm Implementation # Requirements for IS-IS # # Hi, # # This draft follows the ISIS HMAC SHA authentication draft that was # presented in Montreal. # # This document lists down the various authentication schemes and # algorithms that IS-IS can use to authenticate its PDUs. Further to # ensure interop between different # implementations, it specifies a set of MUST/SHOULD/MAY support auth # schemes/algos to ensure that there is atleast 1 auth algo/scheme that # all implementations support. # # This is basically an equivalent of RFC 4305 for IS-IS. # # The nature of cryptography is that new algorithms surface continuously # and existing algorithms are continuously attacked. An algorithm # believed to be strong today may be demonstrated to be weak tomorrow. # Given this, the choice of mandatory-to-implement algorithm should be # conservative so as to minimize the likelihood of it being compromised # quickly. # # Also, we need to recognize that the mandatory-to-implement # algorithm(s) may need to change over time to adapt to the changing # world. For this reason, the selection of mandatory-to-implement # algorithms should not be included in the base IS-IS specification. # This way it is only this document that needs to get updated, whenever # there is a need to update the status of mandatory-to-implement # authentication algorithms or if some authentication algorithms are # deprecated/obsoleted. # # A URL for this Internet-Draft is: # http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto -req-isis-00.txt # # Thanks, # Manav # # > ----- Forwarded Message ---- # > From: Internet-Drafts@ietf.org # > To: i-d-announce@ietf.org # > Sent: Saturday, July 22, 2006 1:20:01 AM # > Subject: I-D ACTION:draft-bhatia-manral-crypto-req-isis-00.txt ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg