From isis-wg-admin@ietf.org Sun Jun 1 06:11:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03845 for ; Sun, 1 Jun 2003 06:11:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51A4YB01582; Sun, 1 Jun 2003 06:04:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51A3RB01516 for ; Sun, 1 Jun 2003 06:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03637; Sun, 1 Jun 2003 06:03:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPel-00058x-00; Sun, 01 Jun 2003 06:01:39 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPek-00058q-00; Sun, 01 Jun 2003 06:01:38 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51A3xf1014092; Sun, 1 Jun 2003 12:04:00 +0200 Message-ID: <3ED9CF5A.7010306@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 12:03:06 +0200 Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Hannes, > > If we agree that having a single 32 bit and/or 64 bit tag is a > good idea then perhaps we could change the wording of the draft to > say that an implementation SHOULD only send and interpret a single > tag and SHOULD ignore data past the first tag. This would allow > the usage of multiple tags to be gracefully deprecated. > > If this isn't acceptable then can we can agree on a small > finite/known number of tags with suggested usage? So, I watched for a while Alex and now Acee trying to influence the direction of this thing (after a last call funny enough) and I definitely do _NOT_ like the direction this is going. I have an understanding for 'exact specification' and 'understanding what the tags are doing' and 'we don't want 64 and 32 bits in place' __BUT__ 1) Slashing the whole thing to things like 1 tag only and squeezing it in size may feel good in terms of specification but it will probably make it as flexible and useful as the OSPF tag, namely completely useless. Just look at the unnatural contortions of RFC 1994. 2) I am lacking to follow the arguments here why multiple tags are so harmfull, why we have to know _exactly_ what every tag means and why the 32 and 64 bit tags together are such a big issue. The only ones I saw were basically 'it may blackhole routes or lead to problems when misconfiguration or implementaion errors occur'. Well, guess what, that's true for almost any RFC that ends up implenented in a screwy way. ISIS is a small implementor's community and we do not have to build specs in a way that every kid hacking Linux can implement it perfectly without having written a protocol in their life before. Therefore, I would encourage the implementors to think whether they want to end up in an OSPF-like tag corset or they want to preserve the flexibility of having multiple tags that can be used in a global or local fashion (global shall necessitate a description for interop-purposes, probaby 2547 extcomm being carried around would be such a thing) or otheriwse for all kind of nice local/proprietary things. BGP extscomms are already used in such way couple of nice & smart ways (I won't go into d3etails to protect the usually suspect vendors ;-) Some of those mechanisms could be used for ISIS to e.g. accelerate convergence on routers supporting these extensions. So, if implementors feel strongly here, please push back on all that 'we'll make it soo much nicer' tweaking and let's try to get this draft out in some decent time rather than the usual 3-infinity years it takes an ISIS RFC to be issued. I would strongly encourage keeping multiple, ordered tags and the draft not touching on their application. I would also encourage a 32 and a 64 bit tag, both being independent address spaces. It's not ideal but what's the point redoing stuff in the field just so the encoding is tad nicer? I would encourage a draft on how the 2547 stuff is being sloshed around using tags. And I think we added a paragraph that when the route selection supresses a route based on a tag we may end up with a blackhole. thanks -- tony > > > Thanks, > Acee > > Hannes Gredler wrote: > >> pls, keep in mind that there is already code in production that allows >> more than one tag; >> >> common use i have seen so far is >> >> tag #1 controls L2L1 leakage >> tag #2 for informational purposes and points to the area of origin; >> >> /hannes >> >> On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: >> | RE: Comments on >> | | Acee, >> | | As the original goal was to create a capability similar to OSPF's >> route tag, >> | it may be wise to drop this capability. On the otherhand, having >> multiple >> | tags per route can provide more information about the route than a >> single >> | tag. In this regard, the 32 bit tag operates more like a >> community, and the >> | 64 bit tag operates like an extended community. From an >> implementation >> | perspective, the same routines for matching and setting these >> fields should >> | be similar to the community fields in BGP. >> | | I would like to solicit the WG for comments on which capability >> is most >> | attractive. The goal is not to introduce too much bloat (is it too >> late for >> | that?!) while still providing some flexibility. >> | | As soon as I receive any final comments, I will release the >> updated draft. >> | | Thanks for pointing out this critical piece! >> | | Regards, >> | chris >> | | >-----Original Message----- >> | >From: Acee Lindem [mailto:acee@redback.com] >> | >Sent: Friday, May 23, 2003 1:50 PM >> | >To: Acee Lindem >> | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area >> | >Directorate >> | >Subject: Re: Comments on >> | > >> | > >> | >Christian, Stefano, Brad, >> | > >> | >The follow-up discussion on the necessity for both 32 bit and >> | >64 bit tags raises the question as to whether or not it is >> | >wise to allow an arbitrary number of tags to be advertised. >> | > >> | > This draft proposes 2 new "Administrative Tag" sub-TLVs >> | >to be added >> | > to TLV 135 and 235. These TLVs specify one or more >> | >ordered, 32 or 64 >> | > ~~~~~~~~~~~~~~~ >> | > bit unsigned integers that may be associated with an IP >> prefix. >> | > >> | >However, the receiver need only use the first. >> | > >> | > An implementation may consider only one of the encoded >> | >tags, in which >> | > case the first encoded tag must be considered. A tag >> | >value of zero >> | > is reserved and should be treated as "no tag". >> | > >> | >IMHO, allowing an arbitrary number of tags affords more >> | >potential for interoperability and deviant applications than >> | >the 64 bit tag. >> | > >> | > >> | > >> | > >> | > >> | >Acee Lindem wrote: >> | >> As a member of the routing area directorate, I have reviewed the >> | >> subject document. Here are my comments: >> | >> >> | >> Comments: >> | >> >> | >> 1. The last sentence of the abstract doesn't make sense. >> | >"Additionally, >> | >> the information can be placed in LSPs that have TLVs as yet >> | >> undefined, if this information is used to convey the same >> | >> meaning in these future TLVs as it used in the currently >> defined >> | >> TLVs". Suggested - "The administrative tag sub-TLVs may >> | >be used with >> | >> with future TLVs as long as their semantics are preserved." >> | >> >> | >> 2. Section 5.2 - The value of the type is wrong - it >> | >should be 2 rather >> | >> than 1. >> | >> >> | >> 3. Section 6 says the ordering of tags is not significant. >> | >However, the >> | >> previous sections (5.1 and 5.2) say that an >> | >implementation may only >> | >> consider the first tag. >> | >> >> | >> 4. Section 7 - List the requirements for receiving the new >> | >Sub-TLVs in >> | >> this compliance section as well (even if they were stated >> | >> previously). >> | >> >> | >> 5. Section 8 - The example talks about R2 associating tag 110 >> with >> | >> property >> | >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix >> | >1.1.1.0/24 with >> | >> property >> | >> A is adjacent to R1 (which applies to me that R1 originate the >> | >> prefix). >> | >> Please fix either the example or the figure. >> | >> >> | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >> | >> >> | >> 1. The abstract contains references. The documents should >> | >be specified >> | >> by name since the abstract can be excerpted. >> | >> >> | >> 2. Line 323 over 72 chars. >> | >> >> | >> Line 323 length is 74 >> | >> Routing in IS-IS", >> | >draft-ietf-isis-wg-multi-topology-03.txt, >> | >> April >> | >> >> | >> 3. Pages 2, 3, 4, and 5 have over 58 lines. >> | >> >> | > >> | > >> | >-- >> | >Acee >> | > >> >> > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 06:26:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03989 for ; Sun, 1 Jun 2003 06:26:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51ALIB02970; Sun, 1 Jun 2003 06:21:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51AKYB02939 for ; Sun, 1 Jun 2003 06:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03893; Sun, 1 Jun 2003 06:20:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPvJ-0005EF-00; Sun, 01 Jun 2003 06:18:46 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPvJ-0005EC-00; Sun, 01 Jun 2003 06:18:45 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51ALCf1016726; Sun, 1 Jun 2003 12:21:13 +0200 Message-ID: <3ED9D362.3080400@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Acee Lindem , Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 12:20:18 +0200 Content-Transfer-Encoding: 7bit > > >I would strongly encourage keeping multiple, ordered tags > oops, glas of wine here, it's 'not-ordered' ... -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 07:48:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04926 for ; Sun, 1 Jun 2003 07:48:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BgKB07706; Sun, 1 Jun 2003 07:42:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BVYB06454 for ; Sun, 1 Jun 2003 07:31:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04713; Sun, 1 Jun 2003 07:31:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MR24-0005QL-00; Sun, 01 Jun 2003 07:29:49 -0400 Received: from ms-smtp-01.southeast.rr.com ([24.93.67.82]) by ietf-mx with esmtp (Exim 4.12) id 19MR23-0005QD-00; Sun, 01 Jun 2003 07:29:47 -0400 Received: from redback.com (rdu26-54-058.nc.rr.com [66.26.54.58]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h51BQ7d2018308; Sun, 1 Jun 2003 07:26:08 -0400 (EDT) Message-ID: <3ED9E375.20009@redback.com> From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 07:28:53 -0400 Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > > >>Hannes, >> >>If we agree that having a single 32 bit and/or 64 bit tag is a >>good idea then perhaps we could change the wording of the draft to >>say that an implementation SHOULD only send and interpret a single >>tag and SHOULD ignore data past the first tag. This would allow >>the usage of multiple tags to be gracefully deprecated. >> >>If this isn't acceptable then can we can agree on a small >>finite/known number of tags with suggested usage? > > > So, I watched for a while Alex and now Acee trying to influence the > direction of this thing (after a last call funny enough) and I definitely > do _NOT_ like the direction this is going. I have an understanding for > 'exact specification' and 'understanding what the tags are doing' and > 'we don't want 64 and 32 bits in place' __BUT__ > > 1) Slashing the whole thing to things like 1 tag only and squeezing it > in size may feel good in terms of specification but it will probably > make > it as flexible and useful as the OSPF tag, namely completely useless. > Just look at the unnatural contortions of RFC 1994. > 2) I am lacking to follow the arguments here why multiple tags are so > harmfull, > why we have to know _exactly_ what every tag means and why the > 32 and 64 bit tags together are such a big issue. The only ones > I saw were basically 'it may blackhole routes or lead to problems > when misconfiguration or implementaion errors occur'. Well, guess > what, that's true for almost any RFC that ends up implenented in > a screwy way. ISIS is a small implementor's community and we do > not have to build specs in a way that every kid hacking Linux can > implement it perfectly without having written a protocol in their life > before. > > Therefore, I would encourage the implementors to think whether they want > to end up in an OSPF-like tag corset or they want to preserve the > flexibility of having multiple tags that can be used in a global or > local fashion > (global shall necessitate a description for interop-purposes, probaby > 2547 extcomm being carried around would be such a thing) or otheriwse > for all kind of nice local/proprietary things. BGP extscomms are already > used in such way couple of nice & smart ways (I won't go into d3etails > to protect the usually suspect vendors ;-) Some of those mechanisms > could be used for ISIS to e.g. accelerate convergence on routers > supporting these extensions. So, if implementors feel strongly here, > please push back on all that 'we'll make it soo much nicer' tweaking and > let's try to get this draft out in some decent time rather than the usual > 3-infinity years it takes an ISIS RFC to be issued. > > I would strongly encourage keeping multiple, ordered tags and the draft > not touching on their application. I would also encourage a 32 and a > 64 bit tag, both being independent address spaces. It's not ideal but > what's the point redoing stuff in the field just so the encoding is tad > nicer? I would encourage a draft on how the 2547 stuff is being sloshed > around using tags. And I think we added a paragraph that when the > route selection supresses a route based on a tag we may end up with > a blackhole. So if we step back, what we have here is a pair of generic TLVs (32 and 64 bits tags) which can be used to send an arbitrary amount of opaque information. Will the tag encodings and their respective applications be described in future drafts? Thanks, -- Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 08:03:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05182 for ; Sun, 1 Jun 2003 08:03:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Bv6B08185; Sun, 1 Jun 2003 07:57:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BuCB08138 for ; Sun, 1 Jun 2003 07:56:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05003; Sun, 1 Jun 2003 07:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MRPu-0005WY-00; Sun, 01 Jun 2003 07:54:26 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MRPt-0005WV-00; Sun, 01 Jun 2003 07:54:25 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51Bupf1030881; Sun, 1 Jun 2003 13:56:52 +0200 Message-ID: <3ED9E9CE.9070803@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> <3ED9E375.20009@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 13:55:58 +0200 Content-Transfer-Encoding: 7bit > > >> >> >> I would strongly encourage keeping multiple, ordered tags and the draft >> not touching on their application. I would also encourage a 32 and a >> 64 bit tag, both being independent address spaces. It's not ideal but >> what's the point redoing stuff in the field just so the encoding is tad >> nicer? I would encourage a draft on how the 2547 stuff is being sloshed >> around using tags. And I think we added a paragraph that when the >> route selection supresses a route based on a tag we may end up with >> a blackhole. > > > So if we step back, what we have here is a pair of generic TLVs (32 > and 64 bits tags) which can be used to send an arbitrary amount of > opaque information. yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred bytes per prefix if you really want to but then, I assume to fix this problem in OSPF you will decleare RFC2370 unlawfull really soon? If the 'hidden communication channel' is the problem you try to solve, security groups will yield a much more fruitfull harvest. > Will the tag encodings and their respective > applications be described in future drafts? That would be very, very desirable but given e.g. EXTCOMMs realities, may only partially come to fruition. I would expect that stuff that has to interoperate would be documented, stuff that does not (e.g. an extension that improves protocol behavior if the other receipient understands it, otherwise yields nothing) not necessarily. Again, RFC2370 comes to mind. thanks - tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 13:25:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23572 for ; Sun, 1 Jun 2003 13:25:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51HJGB28599; Sun, 1 Jun 2003 13:19:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Db6B25231 for ; Sun, 1 Jun 2003 09:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08233; Sun, 1 Jun 2003 09:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MSzW-0006Qu-00; Sun, 01 Jun 2003 09:35:18 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf-mx with esmtp (Exim 4.12) id 19MSzV-0006Qr-00; Sun, 01 Jun 2003 09:35:17 -0400 Received: from redback.com (rdu26-54-058.nc.rr.com [66.26.54.58]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h51DZMtL026526; Sun, 1 Jun 2003 09:35:22 -0400 (EDT) Message-ID: <3EDA00DD.3030408@redback.com> From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> <3ED9E375.20009@redback.com> <3ED9E9CE.9070803@net4u.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 09:34:21 -0400 Content-Transfer-Encoding: 7bit Tony Przygienda wrote: >> >>> >>>I would strongly encourage keeping multiple, ordered tags and the draft >>>not touching on their application. I would also encourage a 32 and a >>>64 bit tag, both being independent address spaces. It's not ideal but >>>what's the point redoing stuff in the field just so the encoding is tad >>>nicer? I would encourage a draft on how the 2547 stuff is being sloshed >>>around using tags. And I think we added a paragraph that when the >>>route selection supresses a route based on a tag we may end up with >>> a blackhole. >> >> >>So if we step back, what we have here is a pair of generic TLVs (32 >>and 64 bits tags) which can be used to send an arbitrary amount of >>opaque information. > > > yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred > bytes per prefix if you really want to but then, I assume to fix this > problem in OSPF > you will decleare RFC2370 unlawfull really soon? Actually, to the best of my knowledge, most of the opaque LSA applications are documented in RFCs and/or drafts (although I know there are undocumented TLVs sent within TE LSAs). > thanks > > - tony > > > -- Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 15:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29598 for ; Sun, 1 Jun 2003 15:18:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51JCWB23154; Sun, 1 Jun 2003 15:12:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51J9gB23053 for ; Sun, 1 Jun 2003 15:09:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28775 for ; Sun, 1 Jun 2003 15:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MYBM-0004M2-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 15:07:52 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19MYBM-0004Lt-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 15:07:52 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 228A223C2F for ; Sun, 1 Jun 2003 11:56:55 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h51J95YB015041 for ; Sun, 1 Jun 2003 12:09:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: Tags Thread-Index: AcMocUQxkU+9/0xeQWea0iav09ZLkw== From: "Tony Li" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h51J9gB23054 Subject: [Isis-wg] Tags Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 1 Jun 2003 12:09:05 -0700 Content-Transfer-Encoding: 8bit A thought: What would happen if we did something similar to BGP communities? To wit: - multiple tags - unordered - 32 bits only - global and local scoping Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 16:17:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01009 for ; Sun, 1 Jun 2003 16:17:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51KEFB26786; Sun, 1 Jun 2003 16:14:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51KBKB26706 for ; Sun, 1 Jun 2003 16:11:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00842 for ; Sun, 1 Jun 2003 16:11:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MZ93-0004js-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:09:33 -0400 Received: from gw.xebeo.com ([204.192.44.242] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19MZ93-0004jp-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:09:33 -0400 Received: (qmail 31904 invoked from network); 1 Jun 2003 20:10:46 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 1 Jun 2003 20:10:46 -0000 Message-ID: <3EDA5DBF.70709@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: isis-wg@ietf.org Subject: Re: [Isis-wg] Tags References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 22:10:39 +0200 Content-Transfer-Encoding: 7bit Tony Li wrote: >A thought: > >What would happen if we did something similar to BGP communities? > >To wit: > >- multiple tags >- unordered >- 32 bits only >- global and local scoping > >Tony > > That's exactly what I'm calling for as well (except if we do just one, 64 for me) and I thought we had more or less nailed with the draft so far. The global vs. local scoping (I asume you mean transitive or not in BGP speech) I don't deem that important since it's an IGP so across-domain doesn't mean much to me in this context ... thanks -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 16:51:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01481 for ; Sun, 1 Jun 2003 16:51:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Kn8B28679; Sun, 1 Jun 2003 16:49:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51KkXB28621 for ; Sun, 1 Jun 2003 16:46:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01413 for ; Sun, 1 Jun 2003 16:46:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MZh7-0004u3-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:44:45 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19MZh7-0004to-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:44:45 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D295534455; Sun, 1 Jun 2003 13:00:54 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h51KjxYB016807; Sun, 1 Jun 2003 13:45:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Tags Message-ID: Thread-Topic: [Isis-wg] Tags Thread-Index: AcMoeegeHEIXHJEyTYGuzEJPUeDzogABLZUQ From: "Tony Li" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h51KkXB28622 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 1 Jun 2003 13:45:59 -0700 Content-Transfer-Encoding: 8bit | >A thought: | > | >What would happen if we did something similar to BGP communities? | > | >To wit: | > | >- multiple tags | >- unordered | >- 32 bits only | >- global and local scoping | > | That's exactly what I'm calling for as well (except if we | do just one, | 64 for me) | and I thought we had more or less nailed with the draft so far. | The global vs. local scoping (I asume you mean transitive | or not in BGP | speech) | I don't deem that important since it's an IGP so | across-domain doesn't mean | much to me in this context ... I'm not seeing a big win with 64 bits, but can be convinced. By local & global scoping, I was suggesting that we divide the range to cover both globally well-known values and also have locally defined/vendor defined values. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 17:05:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02010 for ; Sun, 1 Jun 2003 17:05:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51L27B29518; Sun, 1 Jun 2003 17:02:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51KxvB28971 for ; Sun, 1 Jun 2003 16:59:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01749 for ; Sun, 1 Jun 2003 16:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MZu6-00050B-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:58:10 -0400 Received: from gw.xebeo.com ([204.192.44.242] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19MZu5-000502-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 16:58:09 -0400 Received: (qmail 1252 invoked from network); 1 Jun 2003 20:59:24 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 1 Jun 2003 20:59:24 -0000 Message-ID: <3EDA6925.50402@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: isis-wg@ietf.org Subject: Re: [Isis-wg] Tags References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 22:59:17 +0200 Content-Transfer-Encoding: 7bit Tony Li wrote: > >| >A thought: >| > >| >What would happen if we did something similar to BGP communities? >| > >| >To wit: >| > >| >- multiple tags >| >- unordered >| >- 32 bits only >| >- global and local scoping >| > >| That's exactly what I'm calling for as well (except if we >| do just one, >| 64 for me) >| and I thought we had more or less nailed with the draft so far. >| The global vs. local scoping (I asume you mean transitive >| or not in BGP >| speech) >| I don't deem that important since it's an IGP so >| across-domain doesn't mean >| much to me in this context ... > > >I'm not seeing a big win with 64 bits, but can be convinced. > ok > >By local & global scoping, I was suggesting that we divide the >range to cover both globally well-known values and also have >locally defined/vendor defined values. > agreed -- tony p. > >Tony > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 18:37:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05443 for ; Sun, 1 Jun 2003 18:37:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51MXKB02659; Sun, 1 Jun 2003 18:33:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51MU7B02585 for ; Sun, 1 Jun 2003 18:30:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05329 for ; Sun, 1 Jun 2003 18:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MbJJ-0005fR-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 18:28:17 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19MbJJ-0005fO-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 18:28:17 -0400 Received: from [192.35.166.78] (dhcp2078.nanog28.merit.net [192.35.166.78]) by dog.tcb.net (Postfix) with ESMTP id 2E5E32029A for ; Sun, 1 Jun 2003 16:35:22 -0600 (MDT) User-Agent: Microsoft-Entourage/10.0.0.1309 Subject: Re: [Isis-wg] Tags From: Danny McPherson To: Message-ID: In-Reply-To: <3EDA6925.50402@xebeo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 01 Jun 2003 16:29:01 -0600 Content-Transfer-Encoding: 7bit On 6/1/03 2:59 PM, "Tony Przygienda" wrote: >> I'm not seeing a big win with 64 bits, but can be convinced. >> > ok If the option is 32 or 64, I'd prefer 64, else I suspect we'll see something akin to "IS-IS extended-tags" draft in the near future [Hrmm., perhaps 32 bits is a good idea]. >> >> By local & global scoping, I was suggesting that we divide the >> range to cover both globally well-known values and also have >> locally defined/vendor defined values. >> > agreed What would the initial set of well-known values look like? -danny _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 21:46:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08550 for ; Sun, 1 Jun 2003 21:46:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h521hgB14784; Sun, 1 Jun 2003 21:43:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h521gZB14735 for ; Sun, 1 Jun 2003 21:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08349 for ; Sun, 1 Jun 2003 21:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MeJa-0006UM-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 21:40:46 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19MeJa-0006U9-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 21:40:46 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 04E9834455; Sun, 1 Jun 2003 17:56:23 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h521fSYB022758; Sun, 1 Jun 2003 18:41:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Tags Message-ID: Thread-Topic: [Isis-wg] Tags Thread-Index: AcMojlVF1YfJRP50Rla8wESnJ9TMLgAGXv+w From: "Tony Li" To: "Danny McPherson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h521gZB14736 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 1 Jun 2003 18:41:27 -0700 Content-Transfer-Encoding: 8bit | >> By local & global scoping, I was suggesting that we divide the | >> range to cover both globally well-known values and also have | >> locally defined/vendor defined values. | | What would the initial set of well-known values look like? Dunno and don't particularly care. Just trying to ensure that there is space allocated so that there can be some standardized tags. As we move to more L1/L2 deployments, I can forsee many uses (e.g., internal vs external). Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 1 23:13:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10363 for ; Sun, 1 Jun 2003 23:13:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h523AIB20908; Sun, 1 Jun 2003 23:10:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5239eB20865 for ; Sun, 1 Jun 2003 23:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10304 for ; Sun, 1 Jun 2003 23:09:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mffq-0006y7-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 23:07:50 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19Mffn-0006y3-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 23:07:49 -0400 Received: from l04955 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFU009PR3C9LY@mta0.huawei.com> for isis-wg@ietf.org; Mon, 02 Jun 2003 11:07:23 +0800 (CST) From: lidefeng To: ppvpn@nortelnetworks.com, isis-wg@ietf.org Message-id: <001601c328b4$20cf80c0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Isis-wg] Call for discussion on draft-sheng-ppvpn-isis-bgp-mpls-00.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 11:07:40 +0800 Content-Transfer-Encoding: 7BIT _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 10:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09441 for ; Mon, 2 Jun 2003 10:18:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52EDXB17810; Mon, 2 Jun 2003 10:13:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52ECAB17691 for ; Mon, 2 Jun 2003 10:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08720 for ; Mon, 2 Jun 2003 10:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mq0x-0003KE-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 10:10:19 -0400 Received: from web21511.mail.yahoo.com ([66.163.169.50]) by ietf-mx with smtp (Exim 4.12) id 19Mq0w-0003KB-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 10:10:18 -0400 Message-ID: <20030602141203.20919.qmail@web21511.mail.yahoo.com> Received: from [149.254.120.136] by web21511.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 15:12:03 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational To: Jonathan Sadler , Tony Li Cc: Les Ginsberg , Noguchi Kay , isis-wg@ietf.org In-Reply-To: <3ED63750.15785E80@tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 15:12:03 +0100 (BST) Content-Transfer-Encoding: 8bit I was the one who wrote the paraphrase of three-way handshaking that appears in G.7712, and what a royal pain in the **** it was too. At the time the IETF doc was an Internet Draft. Later when it got an RFC number we were able to put "For more information see RFC xxx" in, but the paraphrase had to remain. As Jonathan said, it would have been much easier if we could have just pointed at the RFC number and said do it that way. After all the ITU can always put "do it such as RFC xyz but with the following exception/addition" if it wants to. Putting it as a standards track takes nothing away from the ITU, but it does make things easier. Philip --- Jonathan Sadler wrote: > > There is certainly more of a struggle to make it a > 'Standard', so > > before anyone proposes to do it, I would suggest > that we contemplate > > the upside. If any. > > > > OSPF is and will continue to be the official > standard IGP of the > > IETF and trying to make IS-IS documents into > standards will likely > > inflame the OSPF vs. IS-IS wars again. And tick > off the ITU. > > I assume you mean "tick off JTC1 (ISO/IEC)". The > ITU is not involved in > the specification of IS-IS. > > However, since the ITU is a "user" of IS-IS, it is > more likely to become > "ticked off" if the IS-IS work in the IETF continues > to be done as > Informational RFCs. This is comes from the fact > that Informational RFCs, > according to the IETF, are not standards. This > results in the ITU not being > able to use them as normative references in an ITU > standard. > > The result is the ITU may need to include a > "paraphrased" version (due to > RFC copyright restrictions) of the IETF > Informational RFC in an ITU > standard. An example where this has already taken > place can be found in > G.7712, where RFC 2966 is paraphrased. > Unfortunately, such parapharsing can > lead to (hopefully unintentionally) different > "specifications" for how an > extension is done. > > Consequently, there is benefit to the ITU by this > document being on the > "standrads track". > > Jonathan Sadler > > > > Lotsa downside... > > > > Tony > > > > | -----Original Message----- > > | From: Les Ginsberg > [mailto:ginsberg@cisco.com] > > | Sent: Wednesday, May 28, 2003 3:45 PM > > | To: Tony Li > > | Cc: Noguchi Kay; isis-wg@ietf.org > > | Subject: RE: [Isis-wg] Re: Last Call: Routing > IPv6 with > > | IS-IS to Informational > > | > > | > > | At 03:20 PM 5/28/2003 -0700, Tony Li wrote: > > | > > | > > | >Same reason as always: we don't have change > control over IS-IS and > > | >we don't want to give the impression that we > do. We might be able > > | >to get away with it for this particular > draft, but > > | frankly, it doesn't > > | >make a lot of difference one way or > another... > > | > > | > > | Sooo..., what is the position of the WG on > > | draft-zinin-ietf-jtc1-aggr-01.txt?? Under > Section 3.1 the > > | IPV6 draft > > | certainly COULD follow the standards track. > Is the WG > > | going to make a > > | calculated decision as to which drafts are > worth following > > | the standards > > | track and which aren't? Are we leaving it to > the discretion of the > > | author(s)? Or are we simply saying "Thanx > very much Alex, > > | but we don't > > | really want to do this work ever?" > > | > > | Les > > | > > | > > | >Tony > > | > > > | > > > | >| -----Original Message----- > > | >| From: Noguchi Kay > [mailto:kay@ipinfusion.com] > > | >| Sent: Wednesday, May 28, 2003 2:50 PM > > | >| To: isis-wg@ietf.org > > | >| Subject: [Isis-wg] Re: Last Call: > Routing IPv6 with IS-IS > > | >| to Informational > > | >| > > | >| > > | >| Hi all, > > | >| > > | >| Maybe I didn't follow the discussion > correctly but let me > > | >| ask you this. > > | >| > > | >| What is the reason we make IPv6 with > IS-IS draft as an > > | >| Informational draft, > > | >| not a Standard draft? > > | >| > > | >| We already shipped softwares based on > this draft and, at > > | >| least, I didn't see > > | >| any discussions about this on the > mailing list. > > | >| > > | >| Thank you, > > | >| > > | >| > > | kay > > | >| > > | >| At Tue, 27 May 2003 18:56:23 -0400, > > | >| The IESG wrote: > > | >| > > > | >| > > > | >| > The IESG has received a request from > the IS-IS for > > | IP Internets > > | >| > Working Group to consider Routing > IPv6 with IS-IS > > | >| > as a > Informational. > > | >| > > > | >| > The IESG plans to make a decision in > the next few weeks, > > | >| and solicits > > | >| > final comments on this action. > Please send any > > | comments to the > > | >| > iesg@ietf.org or ietf@ietf.org > mailing lists by 2003-6-10. > > | >| > > > | >| > Files can be obtained via > > | >| > > > | > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 > > .txt > > >| > > > >| > > > >| > > > >| > > > >| > _______________________________________________ > > >| Isis-wg mailing list > > >| Isis-wg@ietf.org > > >| > https://www1.ietf.org/mailman/listinfo/isis-wg > > >| > _______________________________________________ > > >| Isis-wg-external mailing list > > >| Isis-wg-external@mailist.procket.com > > >| > http://mailist.procket.com/mailman/listinfo/isis-wg-external > > >| > > >_______________________________________________ > > >Isis-wg mailing list > > >Isis-wg@ietf.org > > >https://www1.ietf.org/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > ============================================================ > The information contained in this message may be > privileged > and confidential and protected from disclosure. If > the > reader of this message is not the intended > recipient, or an > employee or agent responsible for delivering this > message to > the intended recipient, you are hereby notified that > any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have > received > this communication in error, please notify us > immediately by > replying to the message and deleting it from your > computer. > === message truncated === __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 10:50:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10410 for ; Mon, 2 Jun 2003 10:50:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Ee8B20523; Mon, 2 Jun 2003 10:40:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Ed8B20436 for ; Mon, 2 Jun 2003 10:39:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10107 for ; Mon, 2 Jun 2003 10:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MqR3-0003XL-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 10:37:17 -0400 Received: from web21511.mail.yahoo.com ([66.163.169.50]) by ietf-mx with smtp (Exim 4.12) id 19MqR3-0003XH-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 10:37:17 -0400 Message-ID: <20030602143902.37602.qmail@web21511.mail.yahoo.com> Received: from [149.254.120.136] by web21511.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 15:39:02 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk To: isis-wg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 15:39:02 +0100 (BST) Content-Transfer-Encoding: 8bit I probably shouldn't be opening an old wound, but I just can't help it... I still say that there is absolutely no point in forming an adjacency between an IPv4-only router and an IPv6-only router. If you do then you cannot forward any traffic over it, so what is the point ? I also think that the MT draft is wrong in this respect. The fact that a sub-topology exists does not reduce the validity of what I have said. Personally I think that the MT draft is over prescriptive on this and consequently makes itself incompatible with autoencap, when it isn't necessary to do so. For autoencap to ever be useful, it would be much, much simpler if the IPv6-only routers would just refuse to connect to the IPv4-only routers. Then autoencap would be useable in a more or less idiot proof fashion. Okay dual routers still would be able to make black holes, but at least the single protocol ones wouldn't. It would be as good as I can get it, though not perfect. As it wouldn't do any harm, why not do it ? What I am proposing is that if an IPv6 capable router can detect no network layer protocols in common with a neighbour then it should not form an adjacency with it. If it can detect one or more in common then it should, on the basis that the adjacency is useful at least for that network layer protocol. Please could it go in the IPv6 RFC ? By the way ITU-T G.7712 already calls for such a clause. By adding it to the RFC then the two would be aligned, making it easier for folks to sell routers to the telecom companies building SONET/SDH DCN networks. Philip __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 11:49:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12783 for ; Mon, 2 Jun 2003 11:49:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FiCB26284; Mon, 2 Jun 2003 11:44:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FhuB26243 for ; Mon, 2 Jun 2003 11:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12557 for ; Mon, 2 Jun 2003 11:43:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MrRo-00049E-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 11:42:08 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19MrRn-000490-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 11:42:08 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52FhKU9019397; Mon, 2 Jun 2003 08:43:20 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACM02118; Mon, 2 Jun 2003 08:43:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602111126.01ed81e8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: isis-wg@ietf.org In-Reply-To: <20030602143902.37602.qmail@web21511.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 11:43:15 -0400 Beating an old drum ... Failing to form adjacencies can cause the DR election to produce different results for different routers, leading to an inoperative network. Therefore it's not a question of something that causes no harm. I used to believe that adjacencies should always be formed, but it turns out the subject is more complicated that I'd thought, and I can't say which is best. I just wanted to point out that refusing to form adjacencies can cause a severe problem. True, the problem can be fixed by careful tuning of DR priority -- but can you write down the rules so that a competent network admin can do it? I'll admit that (at least, without MT) the problems caused by creating an adjacency when there is no connectivity (e.g., when there is no common subnet address) leads to bigger problems than the DR election. Nonetheless, I haven't ever seen anyone who advocates refusing the adjacencies tackle this problem. In the case of no common subnet, the solution is simple: fix the addressing. In the case of multiprotocol, the situation is more complex. Regards, Jeff At 10:39 AM 6/2/2003, Philip Christian wrote: >I probably shouldn't be opening an old wound, but I >just can't help it... > >I still say that there is absolutely no point in >forming an adjacency between an IPv4-only router and >an IPv6-only router. If you do then you cannot >forward any traffic over it, so what is the point ? > >I also think that the MT draft is wrong in this >respect. The fact that a sub-topology exists does not >reduce the validity of what I have said. Personally I >think that the MT draft is over prescriptive on this >and consequently makes itself incompatible with >autoencap, when it isn't necessary to do so. > >For autoencap to ever be useful, it would be much, >much simpler if the IPv6-only routers would just >refuse to connect to the IPv4-only routers. Then >autoencap would be useable in a more or less idiot >proof fashion. Okay dual routers still would be able >to make black holes, but at least the single protocol >ones wouldn't. It would be as good as I can get it, >though not perfect. > >As it wouldn't do any harm, why not do it ? > >What I am proposing is that if an IPv6 capable router >can detect no network layer protocols in common with a >neighbour then it should not form an adjacency with >it. If it can detect one or more in common then it >should, on the basis that the adjacency is useful at >least for that network layer protocol. > >Please could it go in the IPv6 RFC ? > >By the way ITU-T G.7712 already calls for such a >clause. By adding it to the RFC then the two would be >aligned, making it easier for folks to sell routers to >the telecom companies building SONET/SDH DCN networks. > >Philip > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 12:11:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13638 for ; Mon, 2 Jun 2003 12:11:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52G8AB29088; Mon, 2 Jun 2003 12:08:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52G68B28014 for ; Mon, 2 Jun 2003 12:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13500 for ; Mon, 2 Jun 2003 12:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MrnI-0004NF-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 12:04:20 -0400 Received: from web21509.mail.yahoo.com ([66.163.169.58]) by ietf-mx with smtp (Exim 4.12) id 19MrnH-0004NC-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 12:04:19 -0400 Message-ID: <20030602160605.8764.qmail@web21509.mail.yahoo.com> Received: from [149.254.120.136] by web21509.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 17:06:05 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational To: Jeff Learman Cc: isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030602111126.01ed81e8@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 17:06:05 +0100 (BST) Content-Transfer-Encoding: 8bit --- Jeff Learman wrote: > > Nonetheless, I haven't ever seen > anyone who > advocates refusing the adjacencies tackle this > problem. I though that I made a reasonable go at it in section 5.1 of draft-ietf-isis-auto-encap-03.txt If you have a bunch of IPv6-only nodes on a LAN, all ignoring the IPv4-only ones, then they will elect a DIS from amongst themselves, because IOS 10589 states that you elect only from up adjacencies. The IPv4-only nodes will do the same as having been ignored by the IPv6-only ones they don't have an up adjacency with them. You end up with two pseudonodes, one that describes all of the IPv4-only nodes on the LAN, and the other that describes all of the IPv6-only nodes on the LAN, which is actually an accurate picture of the network. I tried this in the lab and it does work very well. I will admit that if you put a dual node on the LAN then things start to go wierd, I have always admitted that. Just because problems A and B cannot both be solved is not a reason to not solve problem A when you get a chance. The IPv6 RFC is such a chance. I think that we should properly crunch some scenarios rather than just dismissing the whole thing as a "problem". It isn't so complicated. These decisions have a way of haunting us for years, and it is worth a few e-mails to get all of the issues out in the open. Philip __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 12:59:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15192 for ; Mon, 2 Jun 2003 12:59:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GtTB32454; Mon, 2 Jun 2003 12:55:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GruB32314 for ; Mon, 2 Jun 2003 12:53:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14940 for ; Mon, 2 Jun 2003 12:53:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsXW-0004gs-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 12:52:06 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19MsXV-0004gm-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 12:52:06 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h52GrFc26030; Mon, 2 Jun 2003 18:53:15 +0200 From: Hannes Gredler To: philip.christian@christiantena.co.uk Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Message-ID: <20030602165315.GA25954@juniper.net> References: <20030602143902.37602.qmail@web21511.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030602143902.37602.qmail@web21511.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 18:53:15 +0200 On Mon, Jun 02, 2003 at 03:39:02PM +0100, Philip Christian wrote: | I probably shouldn't be opening an old wound, but I | just can't help it... | | I still say that there is absolutely no point in | forming an adjacency between an IPv4-only router and | an IPv6-only router. If you do then you cannot | forward any traffic over it, so what is the point ? from a forwarding perpective you do not need to rely on common subnets - you just need somehow resolve the next-hops routers MAC adress [if its bcast] and then forward the traffic to; - agreed - the common subnet rule is a sanity check but from a forwarding perspective not necessary; | I also think that the MT draft is wrong in this | respect. The fact that a sub-topology exists does not | reduce the validity of what I have said. the root cause of the "common subnet rule" is that next-hop resolution on bcast circuits in most OS kernels works via ARP; i.e. if there is no common subnet then the ARP fails and subsequently no next-hop information can be generated due to the missing MAC addresses; common "protocol neutral IS-IS" sense would dictate to resolve the next-hops via extracting SNPAs from IIHs; - however most kernels rely on a per AF L2 address resolution protocol read: ARP, and most routing code does not feedback L2 information back to the kernel; i fail to see why the MT draft is broken from a forwarding perspective ? /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 13:43:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16472 for ; Mon, 2 Jun 2003 13:43:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HcBB04119; Mon, 2 Jun 2003 13:38:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HbSB03760 for ; Mon, 2 Jun 2003 13:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16253 for ; Mon, 2 Jun 2003 13:37:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtDe-0004y8-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 13:35:38 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MtDd-0004xa-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 13:35:37 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52HaljU021684; Mon, 2 Jun 2003 10:36:50 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACM29057; Mon, 2 Jun 2003 10:36:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602133245.01ef1068@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hannes Gredler From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: philip.christian@christiantena.co.uk, isis-wg@ietf.org In-Reply-To: <20030602165315.GA25954@juniper.net> References: <20030602143902.37602.qmail@web21511.mail.yahoo.com> <20030602143902.37602.qmail@web21511.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 13:36:43 -0400 Hannes, what you say is correct, but Philip's point concerned IPV4 vs IPV6, not common subnet addressing (a very closely related issue). If A supports only IPV4 and B supports only IPV6, then there's no way one can forward traffic to the other. So the question is, why should they form an adjacency? My answer is: so that either of them can be elected DR and generate pseudonode LSPs. However, this is a fairly complex subject and I'm not at all certain that my proposition is the best solution. Rather, it's food for thought. Jeff At 12:53 PM 6/2/2003, Hannes Gredler wrote: >On Mon, Jun 02, 2003 at 03:39:02PM +0100, Philip Christian wrote: >| I probably shouldn't be opening an old wound, but I >| just can't help it... >| >| I still say that there is absolutely no point in >| forming an adjacency between an IPv4-only router and >| an IPv6-only router. If you do then you cannot >| forward any traffic over it, so what is the point ? > >from a forwarding perpective you do not need to rely on >common subnets - you just need somehow resolve the >next-hops routers MAC adress [if its bcast] and then >forward the traffic to; - agreed - the common subnet >rule is a sanity check but from a forwarding perspective >not necessary; > >| I also think that the MT draft is wrong in this >| respect. The fact that a sub-topology exists does not >| reduce the validity of what I have said. > >the root cause of the "common subnet rule" is that next-hop >resolution on bcast circuits in most OS kernels works via ARP; >i.e. if there is no common subnet then the ARP fails and >subsequently no next-hop information can be generated due >to the missing MAC addresses; > >common "protocol neutral IS-IS" sense would dictate to resolve >the next-hops via extracting SNPAs from IIHs; - however most kernels >rely on a per AF L2 address resolution protocol read: ARP, >and most routing code does not feedback L2 information back to the kernel; > > >i fail to see why the MT draft is broken from a forwarding perspective ? > >/hannes > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 13:49:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16822 for ; Mon, 2 Jun 2003 13:49:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Hc9B04099; Mon, 2 Jun 2003 13:38:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52HbQB03732 for ; Mon, 2 Jun 2003 13:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16241 for ; Mon, 2 Jun 2003 13:37:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtDb-0004xx-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 13:35:36 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MtDb-0004xZ-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 13:35:35 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52HaljS021684; Mon, 2 Jun 2003 10:36:48 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACM29054; Mon, 2 Jun 2003 10:36:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602123332.01ed9a30@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: isis-wg@ietf.org In-Reply-To: <20030602160605.8764.qmail@web21509.mail.yahoo.com> References: <4.3.2.7.2.20030602111126.01ed81e8@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 12:42:55 -0400 Right -- unless you have a multiprotocol node on the LAN, you don't have problems. But I haven't seen any text on how to deal with the problems caused by multiprotocol nodes. Way back when I posted several problematic scenarios, to deaf ears. So, to summarize (please correct me if I have it wrong): Because they require forming adjacencies between nodes that have no data protocols in common, MT and IPV6 draft are both non-interoperable with auto-encap. Forming adjacencies with all neighbors, as required by 10589, avoids DR election problems. Auto-encap requires rejecting adjacencies with neighbors they have no data protocols in common with. MT and IPV6 have no provisions for automatically plugging holes between protocol "islands" even though it may be possible to connect the islands using tunneling. Any such tunneling must be manually configured. Regards, Jeff At 12:06 PM 6/2/2003, Philip Christian wrote: > --- Jeff Learman wrote: > >> Nonetheless, I haven't ever seen >> anyone who >> advocates refusing the adjacencies tackle this >> problem. > >I though that I made a reasonable go at it in section >5.1 of draft-ietf-isis-auto-encap-03.txt > >If you have a bunch of IPv6-only nodes on a LAN, all >ignoring the IPv4-only ones, then they will elect a >DIS from amongst themselves, because IOS 10589 states >that you elect only from up adjacencies. > >The IPv4-only nodes will do the same as having been >ignored by the IPv6-only ones they don't have an up >adjacency with them. > >You end up with two pseudonodes, one that describes >all of the IPv4-only nodes on the LAN, and the other >that describes all of the IPv6-only nodes on the LAN, >which is actually an accurate picture of the network. > >I tried this in the lab and it does work very well. > >I will admit that if you put a dual node on the LAN >then things start to go wierd, I have always admitted >that. > >Just because problems A and B cannot both be solved is >not a reason to not solve problem A when you get a >chance. The IPv6 RFC is such a chance. > >I think that we should properly crunch some scenarios >rather than just dismissing the whole thing as a >"problem". It isn't so complicated. These decisions >have a way of haunting us for years, and it is worth a >few e-mails to get all of the issues out in the open. > >Philip > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 14:38:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18488 for ; Mon, 2 Jun 2003 14:38:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52IGGB07339; Mon, 2 Jun 2003 14:16:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52IFQB07236 for ; Mon, 2 Jun 2003 14:15:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17787 for ; Mon, 2 Jun 2003 14:15:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MtoN-0005G4-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 14:13:35 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19MtoL-0005Fw-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 14:13:34 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h52IEcI26665; Mon, 2 Jun 2003 20:14:38 +0200 From: Hannes Gredler To: Jeff Learman Cc: philip.christian@christiantena.co.uk, isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Message-ID: <20030602181438.GA26622@juniper.net> References: <20030602143902.37602.qmail@web21511.mail.yahoo.com> <20030602143902.37602.qmail@web21511.mail.yahoo.com> <4.3.2.7.2.20030602133245.01ef1068@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030602133245.01ef1068@dingdong.cisco.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 20:14:38 +0200 On Mon, Jun 02, 2003 at 01:36:43PM -0400, Jeff Learman wrote: | | Hannes, what you say is correct, but Philip's point concerned | IPV4 vs IPV6, not common subnet addressing (a very closely related | issue). | | If A supports only IPV4 and B supports only IPV6, then there's no | way one can forward traffic to the other. So the question is, why | should they form an adjacency? My answer is: so that either of them | can be elected DR and generate pseudonode LSPs. However, this is | a fairly complex subject and I'm not at all certain that my proposition | is the best solution. Rather, it's food for thought. i am not sure .... when we are we talking about "supporting" IPv4 or IPv6 are we talking about "node" properties or "link" properties ? still i wonder about the unnumbered case ... i.e. can there be situations where from a link perspective there are no protocols in common, however from a node perspctive there is; my confusion/curiosity is mainly derived from the unclear semantics of TLV 129 and or presence/absence of 132/232; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 16:37:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23147 for ; Mon, 2 Jun 2003 16:37:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KRGB17979; Mon, 2 Jun 2003 16:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KQNB17942 for ; Mon, 2 Jun 2003 16:26:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22685 for ; Mon, 2 Jun 2003 16:26:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mvr8-00067f-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 16:24:34 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mvr7-00067c-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 16:24:33 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h52KQxf1018580; Mon, 2 Jun 2003 22:26:59 +0200 Message-ID: <3EDBB2DC.3050803@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Learman CC: Hannes Gredler , philip.christian@christiantena.co.uk, isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational References: <20030602143902.37602.qmail@web21511.mail.yahoo.com> <20030602143902.37602.qmail@web21511.mail.yahoo.com> <4.3.2.7.2.20030602133245.01ef1068@dingdong.cisco.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 22:26:04 +0200 Content-Transfer-Encoding: 7bit Jeff Learman wrote: >Hannes, what you say is correct, but Philip's point concerned >IPV4 vs IPV6, not common subnet addressing (a very closely related >issue). > >If A supports only IPV4 and B supports only IPV6, then there's no >way one can forward traffic to the other. So the question is, why >should they form an adjacency? My answer is: so that either of them >can be elected DR and generate pseudonode LSPs. However, this is >a fairly complex subject and I'm not at all certain that my proposition >is the best solution. Rather, it's food for thought. > > yepp, as far I remember the problem was that you have to form adjacencies on Ether to everyone (if you're DR) since otherwise you'll end up with a partionened ether and old-style devices not understanding what possibly went wrong thanks - tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 16:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23286 for ; Mon, 2 Jun 2003 16:47:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KX4B18339; Mon, 2 Jun 2003 16:33:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52KWgB18318 for ; Mon, 2 Jun 2003 16:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22902 for ; Mon, 2 Jun 2003 16:32:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MvxF-00069v-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 16:30:53 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MvxE-00069s-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 16:30:52 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h52KXLf1019864; Mon, 2 Jun 2003 22:33:21 +0200 Message-ID: <3EDBB45A.7070902@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Learman CC: philip.christian@christiantena.co.uk, isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational References: <4.3.2.7.2.20030602111126.01ed81e8@dingdong.cisco.com> <4.3.2.7.2.20030602123332.01ed9a30@dingdong.cisco.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 22:32:26 +0200 Content-Transfer-Encoding: 7bit Jeff Learman wrote: >Right -- unless you have a multiprotocol node on the LAN, you don't >have problems. But I haven't seen any text on how to deal >with the problems caused by multiprotocol nodes. Way back when I >posted several problematic scenarios, to deaf ears. > >So, to summarize (please correct me if I have it wrong): > > Because they require forming adjacencies between nodes that > have no data protocols in common, MT and IPV6 draft are both > non-interoperable with auto-encap. > hmm, how so ? Been a while I read the auto-encap draft. Care for a short summary so we're on same page. > > Forming adjacencies with all neighbors, as required by 10589, > avoids DR election problems. > yes, as far my mind carries, we couldn't find asolution once you had nodes in multiple topologies (incl. #0) and nodes not understanding MT on the same LAN. And this is a real deployment scenario that will need support. It won't help to make our lives easier if we introduce restrictions (you can't run dual-mode on same ether) that are infeasible in the real world. > > Auto-encap requires rejecting adjacencies with neighbors they > have no data protocols in common with. > > MT and IPV6 have no provisions for automatically plugging holes > between protocol "islands" even though it may be possible to > connect the islands using tunneling. Any such tunneling must > be manually configured. > this is a routing protocol, not a network configurator ... -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 17:15:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24347 for ; Mon, 2 Jun 2003 17:15:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LC1B23360; Mon, 2 Jun 2003 17:12:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LBVB23314 for ; Mon, 2 Jun 2003 17:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24180 for ; Mon, 2 Jun 2003 17:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwYn-0006UT-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 17:09:42 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19MwYn-0006TV-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 17:09:41 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52LAraM027012; Mon, 2 Jun 2003 14:10:53 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACM80595; Mon, 2 Jun 2003 14:10:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602170332.01dec3a0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: prz@net4u.ch From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: philip.christian@christiantena.co.uk, isis-wg@ietf.org In-Reply-To: <3EDBB45A.7070902@net4u.ch> References: <4.3.2.7.2.20030602111126.01ed81e8@dingdong.cisco.com> <4.3.2.7.2.20030602123332.01ed9a30@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 17:10:20 -0400 >>So, to summarize (please correct me if I have it wrong): >> >> Because they require forming adjacencies between nodes that >> have no data protocols in common, MT and IPV6 draft are both >> non-interoperable with auto-encap. >> >hmm, how so ? Been a while I read the auto-encap draft. Care for a short >summary so we're on same page. My understanding is that in auto-encap, neighbors that don't have a data protocol in common must refuse to form adjacencies, whereas in MT and IPV6, they must form them regardless. But I'm not really "up" on any of these documents, so I'd like the experts to correct me if I'm wrong! Regards, Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 17:15:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24361 for ; Mon, 2 Jun 2003 17:15:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LB8B23273; Mon, 2 Jun 2003 17:11:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522C9B16818 for ; Sun, 1 Jun 2003 22:12:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09339 for ; Sun, 1 Jun 2003 22:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MemB-0006ip-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 22:10:19 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19MemA-0006iV-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 22:10:19 -0400 Received: from r27907 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFU0064E0OOV9@mta0.huawei.com> for isis-wg@ietf.org; Mon, 02 Jun 2003 10:10:03 +0800 (CST) From: shengcheng To: isis-wg@ietf.org, ppvpn@nortelnetworks.com Cc: stefano previdi , manav@samsung.com, lidefeng@huawei.com, heqian@huawei.com, liu_yu@huawei.com Message-id: <003d01c328ab$94f35700$ca326e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Isis-wg] Fw: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 10:06:29 +0800 Content-Transfer-Encoding: 7BIT Dear all: The below are several emails of the discussion of one doubt about the draft "IS-IS as PE/CE routing protocol in BGP/MPLS/VPN". We wonder if the flooding of LSP accross the Sham link is necessary. According to my opinion, the flooding is not necessary, because sham link is just used to make sure the right next-hop of the VPN-IP route of CE. As per stefano 's view, the flooding is required. But we all agree that it is difficult to flooding the LSP for IS-IS accrossthe sham link because IS-IS is not encapsulated in IP packets as OSPF. Anyone are interested in this topic and can give some good suggestion ? thanks in advance! Sheng ----- Original Message ----- From: "stefano previdi" To: "shengcheng" Cc: ; ; ; Sent: Thursday, May 29, 2003 9:09 PM Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > At 12:49 PM 5/29/2003, shengcheng wrote: > >Stefano: > > > >I don't think the flooding is necessary when the backdoor link fail. > >First, the creation of sham link is just to remove the negative affect by > >backdoor link. when backdoor link fail, sham link is meaningless in fact. > >Second, even we doesn't flush the lsa soon after the backdoor link fail, the > >right result of IS-IS spf route computation will not be affected. > > > I don't agree. If the backdoor link fails, then the two sites cannot > receive the lsp's of the other side. So whatever happens in the one > site will be hidden to the other. However, the sham-link will still > claim connectivity between the two. > > So, the consequence of this is that you have routing inconsistency > between sites with all the issues that are related ti it. > > This is the reason why ospf does flooding over sham-link as well. > > > >With the age of the LSA of the other site's PE and CE in one side, > >the database of the virtual one area (i mean "virtual" is because of sham link) > >may be destroied, but the route table on PE and CE will be still right . > > > >Flooding over sham-link with encapsulation of isis packets into ip almost > >can't be accepted. > > > I know... but you don't have the choice if you want to be sure routing > information is consistent across sites. > > Link-state protocols require that everyone get flooded with all routing > information. If you claim connectivity (sham-link) then you have to be > sure flooding will ALWAYS happen everywhere... which is not the case if > the bakdoor link fails. > > One solution is to shutdown the sham link if the backdoor fails but in > order for this to be possible you have to detect such failure... not > easy without running additional SPFs. > > s. > > > >expect your kindly further discussion.. > > > >regards > >- sheng > > > >----- Original Message ----- > >From: "stefano previdi" > >To: "shengcheng" ; > >Cc: ; ; > >Sent: Thursday, May 29, 2003 3:18 PM > >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > > > > > >On Thursday 29 May 2003 04:11, shengcheng wrote: > >> > >> > >> Dear Stefano and Manav : > >> Thanks for your attention to our draft of ISIS as PE/CE > >> routing protocol in BGP/MPLS VPN. > >> Unluckily, my email box doesn't work normally recently. > >> This is why we give such a late response. > >> Your issue is really very helpful. We are trying to > >> deliver next version of the draft to update the existing > >> problem(including your issues) in the current version this week. > >> Kindly wish you continue to pay attention to the draft ! > >> > >> thanks & regards > >> Sheng > > > >there is something else that need to be worked out. If the > >backdoor link between two sites failed, then the two sites > >do not receive LSPs anymore but still believe they have > >full connectivity through the sham-link. > > > >I'm affraid we will have to specify that flooding should > >occur over the sham link. This complexify a bit the > >architecture (not to mention that flooding over sham-link > >implies encapsulation of isis packets into ip). > > > >s. > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 17:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24693 for ; Mon, 2 Jun 2003 17:24:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LBAB23289; Mon, 2 Jun 2003 17:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522FmB17078 for ; Sun, 1 Jun 2003 22:15:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09553 for ; Sun, 1 Jun 2003 22:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mepi-0006mf-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 22:13:58 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19Mepg-0006mH-00 for isis-wg@ietf.org; Sun, 01 Jun 2003 22:13:57 -0400 Received: from r27907 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFU0079B0UMAW@mta0.huawei.com> for isis-wg@ietf.org; Mon, 02 Jun 2003 10:13:40 +0800 (CST) From: shengcheng To: isis-wg@ietf.org, ppvpn@nortelnetworks.com Cc: stefano previdi , manav@samsung.com, liu_y@huawei.com, lidefeng@huawei.com, heqian@huawei.com Message-id: <005201c328ac$144d44c0$ca326e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002c01c32587$a594a220$ca326e0a@HUAWEI.COM> <200305290718.h4T7I6R21806@strange-brew.cisco.com> <4.3.2.7.2.20030529150445.01a06980@strange-brew.cisco.com> <4.3.2.7.2.20030530101958.0340d008@strange-brew.cisco.com> Content-Transfer-Encoding: 7BIT Subject: [Isis-wg] Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 10:10:02 +0800 Content-Transfer-Encoding: 7BIT This is for your information. Thanks & Regards Sheng ----- Original Message ----- From: "stefano previdi" To: "shengcheng" Cc: ; ; ; Sent: Friday, May 30, 2003 4:30 PM Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > At 05:58 AM 5/30/2003, shengcheng wrote: > >Stefano: > > As you have said "So, the consequence of this is that you have routing inconsistency > > between sites with all the issues that are related ti it." . What do you mean the "routing inconsistency?" > > > whatever changes in one site will be unknown to the other > one. This may result in routing loops (e.g.: a prefix is > withdrawn from one site and advertised by another one). > > sham-link is considered as a p2p link. If flooding is > stopped because there is no other connectivity than the > sham-link, then the flooding scheme is broken. > > > >Yes the database sychronization has been destroied, but i still think the route is right in PE/CE of > >both side. > > > The PEs _may_ have correct information but not the CEs and > not all the other routers in both sites. CEs and sites will > only have local information and out-of-date information > about the other site. > > > > It is really a disaster for IS-IS to encapsulate its packet in IP format, which is the only way to > >flood the LSP accross the sham link in my opinion. > > > if you want to flood between sites you have to use IP. Note > that you will encap also CSNP/PSNP packets because of reliable > flooding (IP is just the encap). > > > >I think your suggention about shutting down the sham > >link when detecting the backdoor fails is a good idea. Maybe it is the only method that deserve our > >further attention when we have to fufill the database synchronization of IS-IS as a link state protocol. > > > detecting the failure of the backdoor is not trivial. the PE > doesn't know who is the backdoor. The only way to do so is to > run an additional SPF with following constraints: > > 1- do not use the sham-link in the computation > 2- check reachability of the other PE > > if the other PE is found after this special SPF than it means > the backdoor works. If not it means that the sham-link is the > only way to reach the other PE. But you understand that this > means the PE has to run one more SPF at each network change. > > So now the question is: what do we do if the backdoor link > fails ? If you just shutdown the sham-link, then you completely > lose connectivity between sites and it is not the scope of the > game... > > So the alternative is to _always_ redistribute sites routes > into BGP (even if you do flooding over sham-link) so when the > sham-link is shutdown you can rely on mp-bgp to propagate routes > between sites. This has the side effect of flooding twice the > routes... > > s. > > > > >Do you have other constructive suggestion? > > > > > >thanks®ards > >Sheng > > > >----- Original Message ----- > >From: "stefano previdi" > >To: "shengcheng" > >Cc: ; ; ; > >Sent: Thursday, May 29, 2003 9:09 PM > >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > > > > > >> At 12:49 PM 5/29/2003, shengcheng wrote: > >> >Stefano: > >> > > >> >I don't think the flooding is necessary when the backdoor link fail. > >> >First, the creation of sham link is just to remove the negative affect by > >> >backdoor link. when backdoor link fail, sham link is meaningless in fact. > >> >Second, even we doesn't flush the lsa soon after the backdoor link fail, the > >> >right result of IS-IS spf route computation will not be affected. > >> > >> > >> I don't agree. If the backdoor link fails, then the two sites cannot > >> receive the lsp's of the other side. So whatever happens in the one > >> site will be hidden to the other. However, the sham-link will still > >> claim connectivity between the two. > >> > >> So, the consequence of this is that you have routing inconsistency > >> between sites with all the issues that are related ti it. > >> > >> This is the reason why ospf does flooding over sham-link as well. > >> > >> > >> >With the age of the LSA of the other site's PE and CE in one side, > >> >the database of the virtual one area (i mean "virtual" is because of sham link) > >> >may be destroied, but the route table on PE and CE will be still right . > >> > > >> >Flooding over sham-link with encapsulation of isis packets into ip almost > >> >can't be accepted. > >> > >> > >> I know... but you don't have the choice if you want to be sure routing > >> information is consistent across sites. > >> > >> Link-state protocols require that everyone get flooded with all routing > >> information. If you claim connectivity (sham-link) then you have to be > >> sure flooding will ALWAYS happen everywhere... which is not the case if > >> the bakdoor link fails. > >> > >> One solution is to shutdown the sham link if the backdoor fails but in > >> order for this to be possible you have to detect such failure... not > >> easy without running additional SPFs. > >> > >> s. > >> > >> > >> >expect your kindly further discussion.. > >> > > >> >regards > >> >- sheng > >> > > >> >----- Original Message ----- > >> >From: "stefano previdi" > >> >To: "shengcheng" ; > >> >Cc: ; ; > >> >Sent: Thursday, May 29, 2003 3:18 PM > >> >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > >> > > >> > > >> >On Thursday 29 May 2003 04:11, shengcheng wrote: > >> >> > >> >> > >> >> Dear Stefano and Manav : > >> >> Thanks for your attention to our draft of ISIS as PE/CE > >> >> routing protocol in BGP/MPLS VPN. > >> >> Unluckily, my email box doesn't work normally recently. > >> >> This is why we give such a late response. > >> >> Your issue is really very helpful. We are trying to > >> >> deliver next version of the draft to update the existing > >> >> problem(including your issues) in the current version this week. > >> >> Kindly wish you continue to pay attention to the draft ! > >> >> > >> >> thanks & regards > >> >> Sheng > >> > > >> >there is something else that need to be worked out. If the > >> >backdoor link between two sites failed, then the two sites > >> >do not receive LSPs anymore but still believe they have > >> >full connectivity through the sham-link. > >> > > >> >I'm affraid we will have to specify that flooding should > >> >occur over the sham link. This complexify a bit the > >> >architecture (not to mention that flooding over sham-link > >> >implies encapsulation of isis packets into ip). > >> > > >> >s. > >> > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 17:38:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25343 for ; Mon, 2 Jun 2003 17:38:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LXAB24685; Mon, 2 Jun 2003 17:33:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LWUB24647 for ; Mon, 2 Jun 2003 17:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24975 for ; Mon, 2 Jun 2003 17:32:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mwt6-0006fj-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 17:30:40 -0400 Received: from web21506.mail.yahoo.com ([66.163.169.17]) by ietf-mx with smtp (Exim 4.12) id 19Mwt5-0006fg-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 17:30:39 -0400 Message-ID: <20030602213225.19628.qmail@web21506.mail.yahoo.com> Received: from [80.194.91.4] by web21506.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 22:32:25 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational To: prz@net4u.ch, Jeff Learman Cc: isis-wg@ietf.org In-Reply-To: <3EDBB45A.7070902@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 22:32:25 +0100 (BST) Content-Transfer-Encoding: 8bit MT has a clause in it that you always form an adjacency on a LAN whatever. It says so in section 5.2 "Two Routers on a LAN SHALL always establish adjacency regardless whether they have common MT set or not. This is to ensure all the routers on the LAN can correctly elect the same DIS. " However this does not make MT incompatible with autoencap. However I believe that the MT draft doesn't really have the right to make that statement anyway. It is nothing to do with MT, it's rather a general IS-IS issue, and it isn't necessary to make MT work, which is why I said that it is overprescriptive. Having a correctly elected DIS is a general IS-IS issue, not particularly an MT issue. I don't see why the MT draft has to address it. Other than that issue MT is perfectly compatible with autoencap, especially if any LANs used are kept simple (like don't use an MT node, a dual node and a uniprotocol node on the same LAN). A simple MT to autoencap link (LAN or otherwise) will work fine. Also to say that the IPv6 draft is not compatible with autoencap is flat out wrong. Autoencap does rely on an IPv6-only and an IPv4-only node not having an adjacency. This can be acheived by a: A rule such as the that I am proposing, as per G.7712. b: Just don't put an IPv4-only and IPv6-only node on the same LAN. or c: Manually disable any such adjacency. As long as there are no non-autoencap dual nodes on the LAN then you won't get into problems with DIS. Use any of these three and autoencap will interwork with IS-IS routed IPv6 perfectly, even as the draft stands. Also manual tunnels don't work that well either. You can't tell IS-IS to use the tunnel for IPv6 but not for IPv4. You end up sending all traffic down the tunnel whether it could go natively or not. You end up with (IPv4+IPv6+ISIS)/GRE/IPv4 for example. Philip --- Tony Przygienda wrote: > Jeff Learman wrote: > > >Right -- unless you have a multiprotocol node on > the LAN, you don't > >have problems. But I haven't seen any text on how > to deal > >with the problems caused by multiprotocol nodes. > Way back when I > >posted several problematic scenarios, to deaf ears. > > > >So, to summarize (please correct me if I have it > wrong): > > > > Because they require forming adjacencies between > nodes that > > have no data protocols in common, MT and IPV6 > draft are both > > non-interoperable with auto-encap. > > > hmm, how so ? Been a while I read the auto-encap > draft. Care for a short > summary > so we're on same page. > > > > > Forming adjacencies with all neighbors, as > required by 10589, > > avoids DR election problems. > > > yes, as far my mind carries, we couldn't find > asolution once you had nodes > in multiple topologies (incl. #0) and nodes not > understanding MT on the > same > LAN. And this is a real deployment scenario that > will need support. It > won't help > to make our lives easier if we introduce > restrictions (you can't run > dual-mode on > same ether) that are infeasible in the real world. > > > > > Auto-encap requires rejecting adjacencies with > neighbors they > > have no data protocols in common with. > > > > MT and IPV6 have no provisions for automatically > plugging holes > > between protocol "islands" even though it may be > possible to > > connect the islands using tunneling. Any such > tunneling must > > be manually configured. > > > this is a routing protocol, not a network > configurator ... > > -- tony > > > > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 18:34:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28071 for ; Mon, 2 Jun 2003 18:34:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52MV9B29353; Mon, 2 Jun 2003 18:31:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52MULB29306 for ; Mon, 2 Jun 2003 18:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27898 for ; Mon, 2 Jun 2003 18:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mxn4-000757-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:28:30 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 19Mxn3-000754-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:28:29 -0400 Message-ID: <20030602223015.49378.qmail@web21502.mail.yahoo.com> Received: from [80.194.91.4] by web21502.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 23:30:15 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational To: prz@net4u.ch, Jeff Learman Cc: isis-wg@ietf.org In-Reply-To: <20030602213225.19628.qmail@web21506.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 23:30:15 +0100 (BST) Content-Transfer-Encoding: 8bit I think that this is the specific scenario that becomes broken if IPv4 and IPv6 nodes don't have an adjacency. The number above the node is the priority. 3 1 2 +----+ +----+ +-----+ | v4 | | v6 | | 4/6 | +--+-+ +--+-+ +-+---+ | | | -+-------+------+- LAN In this case the v6 node sees the higher priority of the 4/6 node and so doesn't make a pseudonode. The 4/6 node sees the v4 node and so doesn't make a pseudonode. The v4 node sees only the 4/6 node and so makes a pseudonode, but only includes the 4/6 node as connected to the pseudonode. Thus, another IS viewing the LAN from afar will think that the v6 node is not connected and so will not plot a route through it, as it isn't included in the pseudonode LSP. Without autoencap you could use this topology, but only very carefully. You would have to make sure that no IPv6 destinations lie beyond the v4 node, and that no IPv4 destinations lie beyond the v6 node. In this way you can guarantee that SPF will never send an IPv4 packet through the v6 node and vice versa, as all v4 destinations are through the 4/6 node. On this particular point, an adjacency rule such as G.7712s does stop a usable route being formed where otherwise it would be formed. The topology is however illegal under RFC 1195 and one would be ill advised to use it. Many vendors won't implementations won't work in this scenario anyway. If you set the dual node higher than the others then it works because you get a single pseudonode declaring adjacencies to all others. If you set the dual node lower than the others then it works because you get two pseudonodes both declaring an adjacency to the dual. It only breaks if the dual node is higher than all v4 nodes, but lower than a v6 node, or the other way around. Philip __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 19:02:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29196 for ; Mon, 2 Jun 2003 19:02:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52MuIB31445; Mon, 2 Jun 2003 18:56:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Mt4B31398 for ; Mon, 2 Jun 2003 18:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28690 for ; Mon, 2 Jun 2003 18:54:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MyAy-0007Gr-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:53:12 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19MyAx-0007Gh-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:53:11 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h52MsOHr013793; Mon, 2 Jun 2003 15:54:24 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACN04304; Mon, 2 Jun 2003 15:54:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602175811.01e1f0a0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: prz@net4u.ch, isis-wg@ietf.org In-Reply-To: <20030602213225.19628.qmail@web21506.mail.yahoo.com> References: <3EDBB45A.7070902@net4u.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 18:20:23 -0400 OK, I thought the auto-encap doc specifically said to NOT form adjacencies when you have no data protocols in common, in which case it would contradict MT. In general, if one protocol says you MUST do A, and another says you MUST NOT do A, they're incompatible and non-interoperable. In this case, though, it's not that cut-and-dried, as you pointed out. More below. At 05:32 PM 6/2/2003, Philip Christian wrote: >MT has a clause in it that you always form an >adjacency on a LAN whatever. It says so in section >5.2 > >"Two Routers on a LAN SHALL always establish adjacency >regardless whether they have common MT set or not. >This is to ensure all the routers on the LAN can >correctly elect the same DIS. " > >However this does not make MT incompatible with >autoencap. Glad to hear it! >However I believe that the MT draft >doesn't really have the right to make that statement >anyway. It is nothing to do with MT, it's rather a >general IS-IS issue, and it isn't necessary to make MT >work, which is why I said that it is overprescriptive. >Having a correctly elected DIS is a general IS-IS >issue, not particularly an MT issue. I don't see why >the MT draft has to address it. If it's necessary anyway, then why not say it? 10589 isn't the best source because it's not multiprotocol. I don't remember whether RFC 1195 is explicit or not, nonetheless the question used to come up all the time. In MT, the deployment requirements of 1195 are relaxed, and this might or might not mean a change in this kind of policy. MT gives the requirement and the reason for it. >Other than that issue MT is perfectly compatible with >autoencap, especially if any LANs used are kept simple >(like don't use an MT node, a dual node and a >uniprotocol node on the same LAN). A simple MT to >autoencap link (LAN or otherwise) will work fine. > >Also to say that the IPv6 draft is not compatible with >autoencap is flat out wrong. Once again, I thought that IPv6 requires forming adjacencies that auto-encap requires to be refused. >Autoencap does rely on an IPv6-only and an IPv4-only >node not having an adjacency. This can be acheived by > >a: A rule such as the that I am proposing, as per >G.7712. > >b: Just don't put an IPv4-only and IPv6-only node on >the same LAN. > >or > >c: Manually disable any such adjacency. As long as >there are no non-autoencap dual nodes on the LAN then >you won't get into problems with DIS. > >Use any of these three and autoencap will interwork >with IS-IS routed IPv6 perfectly, even as the draft >stands. So it appears that auto-encap can be used with MT and IPv6, as long as certain deployment rules are followed. Are these rules documented? Probably not, since auto-encap preceded the others. It would be worthwhile to document them officially. >Also manual tunnels don't work that well either. You >can't tell IS-IS to use the tunnel for IPv6 but not >for IPv4. You end up sending all traffic down the >tunnel whether it could go natively or not. You end >up with (IPv4+IPv6+ISIS)/GRE/IPv4 for example. Before MT, manual tunnels don't work at all. I would have thought that manual tunnels plus MT would work just fine, because you CAN tell IS-IS to use the tunnel (link) just for specific protocols. I'll have to reread MT -- like I said, I'm not an expert on that; I'm just going on my recollection. Sorry if I've muddied the water. Jeff >Philip > > > > --- Tony Przygienda wrote: > Jeff >Learman wrote: >> >> >Right -- unless you have a multiprotocol node on >> the LAN, you don't >> >have problems. But I haven't seen any text on how >> to deal >> >with the problems caused by multiprotocol nodes. >> Way back when I >> >posted several problematic scenarios, to deaf ears. >> > >> >So, to summarize (please correct me if I have it >> wrong): >> > >> > Because they require forming adjacencies between >> nodes that >> > have no data protocols in common, MT and IPV6 >> draft are both >> > non-interoperable with auto-encap. >> > >> hmm, how so ? Been a while I read the auto-encap >> draft. Care for a short >> summary >> so we're on same page. >> >> > >> > Forming adjacencies with all neighbors, as >> required by 10589, >> > avoids DR election problems. >> > >> yes, as far my mind carries, we couldn't find >> asolution once you had nodes >> in multiple topologies (incl. #0) and nodes not >> understanding MT on the >> same >> LAN. And this is a real deployment scenario that >> will need support. It >> won't help >> to make our lives easier if we introduce >> restrictions (you can't run >> dual-mode on >> same ether) that are infeasible in the real world. >> >> > >> > Auto-encap requires rejecting adjacencies with >> neighbors they >> > have no data protocols in common with. >> > >> > MT and IPV6 have no provisions for automatically >> plugging holes >> > between protocol "islands" even though it may be >> possible to >> > connect the islands using tunneling. Any such >> tunneling must >> > be manually configured. >> > >> this is a routing protocol, not a network >> configurator ... >> >> -- tony >> >> > >> > >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 19:06:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29275 for ; Mon, 2 Jun 2003 19:06:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52MuLB31464; Mon, 2 Jun 2003 18:56:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52Mt8B31403 for ; Mon, 2 Jun 2003 18:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28693 for ; Mon, 2 Jun 2003 18:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MyB2-0007Gx-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:53:16 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19MyB1-0007Gi-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 18:53:15 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h52MsOHv013793; Mon, 2 Jun 2003 15:54:29 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACN04309; Mon, 2 Jun 2003 15:54:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20030602184847.01e88b98@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: prz@net4u.ch, isis-wg@ietf.org In-Reply-To: <20030602223015.49378.qmail@web21502.mail.yahoo.com> References: <20030602213225.19628.qmail@web21506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 18:54:21 -0400 This is one bad case. It gets a little more complicated when there are 3 or more protocols involved, and the solutions aren't quite as simple. There might be another bad case for 2 protocols, but I'll have to think about it. The topology is illegal for 1195, but is it illegal for MT? Regards, Jeff At 06:30 PM 6/2/2003, Philip Christian wrote: >I think that this is the specific scenario that >becomes broken if IPv4 and IPv6 nodes don't have an >adjacency. > >The number above the node is the priority. > > 3 1 2 >+----+ +----+ +-----+ >| v4 | | v6 | | 4/6 | >+--+-+ +--+-+ +-+---+ > | | | > -+-------+------+- > LAN > >In this case the v6 node sees the higher priority of >the 4/6 node and so doesn't make a pseudonode. > >The 4/6 node sees the v4 node and so doesn't make a >pseudonode. > >The v4 node sees only the 4/6 node and so makes a >pseudonode, but only includes the 4/6 node as >connected to the pseudonode. > >Thus, another IS viewing the LAN from afar will think >that the v6 node is not connected and so will not plot >a route through it, as it isn't included in the >pseudonode LSP. > >Without autoencap you could use this topology, but >only very carefully. > >You would have to make sure that no IPv6 destinations >lie beyond the v4 node, and that no IPv4 destinations >lie beyond the v6 node. In this way you can guarantee >that SPF will never send an IPv4 packet through the v6 >node and vice versa, as all v4 destinations are >through the 4/6 node. > >On this particular point, an adjacency rule such as >G.7712s does stop a usable route being formed where >otherwise it would be formed. The topology is however >illegal under RFC 1195 and one would be ill advised to >use it. Many vendors won't implementations won't work >in this scenario anyway. > >If you set the dual node higher than the others then >it works because you get a single pseudonode declaring >adjacencies to all others. > >If you set the dual node lower than the others then it >works because you get two pseudonodes both declaring >an adjacency to the dual. > >It only breaks if the dual node is higher than all v4 >nodes, but lower than a v6 node, or the other way >around. > >Philip > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 21:27:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02813 for ; Mon, 2 Jun 2003 21:27:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531ONB10012; Mon, 2 Jun 2003 21:24:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531NTB09927 for ; Mon, 2 Jun 2003 21:23:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02689; Mon, 2 Jun 2003 21:23:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0Ud-0000Vo-00; Mon, 02 Jun 2003 21:21:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19N0Uc-0000Vk-00; Mon, 02 Jun 2003 21:21:38 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19N0WL-000Eqt-00; Tue, 03 Jun 2003 01:23:25 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3859276824.20030602182256@psg.com> To: isis-wg@ietf.org CC: Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 18:22:56 -0700 Content-Transfer-Encoding: 7bit Tony, Acee, et al. I think I should clarify some points here, specifically what I am and am not concerned with and why. What I do NOT have a problem with (non-issues): NI-1. The opaque nature of a route tag as an integer attached to a route NI-2. Presence of a 32-bit and a 64-bit tag simultaneously if there is a real reason for this. NI-3. Even more than one tag, as long as they are used as _tags_, though I can't see how more than 2 or 3 tags would be useful. However, what concerns me is (issues with discussions, please feel free to comment): I-1. Tag TLVs introduced as any-size opaque transport containers, such inflatable "goodie-bags" with practically no internal structure (except for n x 32, or n x 64) where one can find tags, but also "all kind of nice proprietary things". Is there a risk that these TLVs will be used to carry "stuff" around? Reviewing the thread, seems that Acee, Tony P. and I agree that this is possible: "...yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred bytes per prefix if you really want to..." What's the risk that this will happen? What is the risk that more than one vendor will do that? Is this dangerous? Are we going to see collisions among vendors in the field? Plus all arguments we have seen against vendor-specific extensions during the discussion on experimental TLVs are applicable (issues with interop, security, changes in proto dynamics, lack of community review, etc.) It seems that the WG needs to consider these arguments. I-2. The problem of distributing 2547-related attributes addressed by introduction of the n x 64-bit opaque TLV, called 'tag'. Why are we overloading the notion of tag from the very beginning? Why not have a separate TLV and a proper spec for this? This goes hand in hand with the question of why we need another tag. If we assume that the right answer to transportation of the 2547 attributes is a separate TLV with a proper specification of what is put there and how to act on it, then we need to answer the question "do we need the second tag?" If we read the draft as it stands, with the main application being route "color" and control over prefix distribution, the second tag does not seem necessary. Also, the size of the tag (8 octets) raises the risk of "stuff" being put into it, though it is admittedly much lower than the risk introduced by I-1 To comment on some points Tony P. brought up (those not implicitly addressed above): 1. Why we should know what every tag means? I don't believe we should (see NI-1). On the other hand, if the document intends to say that one of the applications of the tag is to control route distribution, it should request that compliant implementations support tag-based prefix filtering. Otherwise compliance to the spec will not mean anything to the SP who want to actually control prefix distribution. 2. What about OSPF Opaque LSAs and BGP Extended Communities? It seems to me that the difference between them and the current tag proposal is in the level at which opaqueness is introduced and presence of the internal structure. More specifically, before Opaque LSAs were introduced, each new LSA type required modification of OSPF SW. Opaque LSAs abstract transport details of LSA flooding from the description of LSA payload. This helps to avoid having to modify the SW every time a new LSA is introduced. (However, each Opaque LSA type needs to be registered by IANA through the OSPF WG, which outlaws just grabbing an LSA to distribute proprietary stuff.) ISIS already has this level of opaqueness through the notion of TLVs. Regular BGP communities (RFC1997) are constructed as a set of one or more 32-bit values, which seems very close to the description of the 32-bit tag TLV in the draft. The difference is in the fact that some internal structure is provided at least for admin assignment, and that some values are reserved and defined as well-known, with well-defined behavior, which enforces their use as tags. Extended communities are also different, since each ext community is encoded as Type/Value couple, with internal structure specific to a type, sub-types allocated by IANA, and fixed-length values. I hope this clarifies my concerns and will help the discussion. Thanks. Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 21:28:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02844 for ; Mon, 2 Jun 2003 21:28:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531Q1B10114; Mon, 2 Jun 2003 21:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531PVB10084 for ; Mon, 2 Jun 2003 21:25:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02729; Mon, 2 Jun 2003 21:25:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0Wa-0000Wo-00; Mon, 02 Jun 2003 21:23:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19N0WZ-0000Wl-00; Mon, 02 Jun 2003 21:23:39 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19N0YE-000EwM-00; Tue, 03 Jun 2003 01:25:22 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <44859393983.20030602182453@psg.com> To: Hannes Gredler CC: Acee Lindem , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <20030530222903.GA11581@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <20030530222903.GA11581@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 18:24:53 -0700 Content-Transfer-Encoding: 7bit Hannes, Are the tag and tag2 both 32-bit tags taken from the same TLV or do you have the 64-bit tags coded/deployed also? -- Alex http://www.psg.com/~zinin/ Friday, May 30, 2003, 3:29:03 PM, Hannes Gredler wrote: > acee, > our implementation currently support two tags > and we pass it on in a ordered way for > internal policy-processing e.g. first tag found is copied > to the variable "tag" and the second tag is > copied to the variable "tag2"; both variables can be > matched against in our internal policy processing > language; > and thats IMHO the only place > where the draft needs to be more specific: > how an implementation [order, etc.] maps IS-IS-tags > to match-clauses in the local policy processor; > i am unsure about the ordering and number of supported tags > of other implementations; > stefano, can you shed some light ? > --- > SHOULD is IMO a bit too strong wording, i'd be happy > with something like "MAY have more than one tag" > /hannes > On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: > | Hannes, > | > | If we agree that having a single 32 bit and/or 64 bit tag is a > | good idea then perhaps we could change the wording of the draft to > | say that an implementation SHOULD only send and interpret a single > | tag and SHOULD ignore data past the first tag. This would allow > | the usage of multiple tags to be gracefully deprecated. > | > | If this isn't acceptable then can we can agree on a small > | finite/known number of tags with suggested usage? > | > | Thanks, > | Acee > | > | Hannes Gredler wrote: | >>pls, keep in mind that there is already code in production that allows | >>more than one tag; | >> | >>common use i have seen so far is | >> | >>tag #1 controls L2L1 leakage | >>tag #2 for informational purposes and points to the area of origin; | >> | >>/hannes | >> | >>On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | >>| RE: Comments on | >>| | >>| Acee, | >>| | >>| As the original goal was to create a capability similar to OSPF's route | >>tag, | >>| it may be wise to drop this capability. On the otherhand, having | >>multiple | >>| tags per route can provide more information about the route than a single | >>| tag. In this regard, the 32 bit tag operates more like a community, and | >>the | >>| 64 bit tag operates like an extended community. From an implementation | >>| perspective, the same routines for matching and setting these fields | >>should | >>| be similar to the community fields in BGP. | >>| | >>| I would like to solicit the WG for comments on which capability is most | >>| attractive. The goal is not to introduce too much bloat (is it too late | >>for | >>| that?!) while still providing some flexibility. | >>| | >>| As soon as I receive any final comments, I will release the updated | >>draft. | >>| | >>| Thanks for pointing out this critical piece! | >>| | >>| Regards, | >>| chris | >>| | >>| >-----Original Message----- | >>| >From: Acee Lindem [mailto:acee@redback.com] | >>| >Sent: Friday, May 23, 2003 1:50 PM | >>| >To: Acee Lindem | >>| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >>| >Directorate | >>| >Subject: Re: Comments on | >>| > | >>| > | >>| >Christian, Stefano, Brad, | >>| > | >>| >The follow-up discussion on the necessity for both 32 bit and | >>| >64 bit tags raises the question as to whether or not it is | >>| >wise to allow an arbitrary number of tags to be advertised. | >>| > | >>| > This draft proposes 2 new "Administrative Tag" sub-TLVs | >>| >to be added | >>| > to TLV 135 and 235. These TLVs specify one or more | >>| >ordered, 32 or 64 | >>| > ~~~~~~~~~~~~~~~ | >>| > bit unsigned integers that may be associated with an IP prefix. | >>| > | >>| >However, the receiver need only use the first. | >>| > | >>| > An implementation may consider only one of the encoded | >>| >tags, in which | >>| > case the first encoded tag must be considered. A tag | >>| >value of zero | >>| > is reserved and should be treated as "no tag". | >>| > | >>| >IMHO, allowing an arbitrary number of tags affords more | >>| >potential for interoperability and deviant applications than | >>| >the 64 bit tag. | >>| > | >>| > | >>| > | >>| > | >>| > | >>| >Acee Lindem wrote: | >>| >> As a member of the routing area directorate, I have reviewed the | >>| >> subject document. Here are my comments: | >>| >> | >>| >> Comments: | >>| >> | >>| >> 1. The last sentence of the abstract doesn't make sense. | >>| >"Additionally, | >>| >> the information can be placed in LSPs that have TLVs as yet | >>| >> undefined, if this information is used to convey the same | >>| >> meaning in these future TLVs as it used in the currently defined | >>| >> TLVs". Suggested - "The administrative tag sub-TLVs may | >>| >be used with | >>| >> with future TLVs as long as their semantics are preserved." | >>| >> | >>| >> 2. Section 5.2 - The value of the type is wrong - it | >>| >should be 2 rather | >>| >> than 1. | >>| >> | >>| >> 3. Section 6 says the ordering of tags is not significant. | >>| >However, the | >>| >> previous sections (5.1 and 5.2) say that an | >>| >implementation may only | >>| >> consider the first tag. | >>| >> | >>| >> 4. Section 7 - List the requirements for receiving the new | >>| >Sub-TLVs in | >>| >> this compliance section as well (even if they were stated | >>| >> previously). | >>| >> | >>| >> 5. Section 8 - The example talks about R2 associating tag 110 with | >>| >> property | >>| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >>| >1.1.1.0/24 with | >>| >> property | >>| >> A is adjacent to R1 (which applies to me that R1 originate the | >>| >> prefix). | >>| >> Please fix either the example or the figure. | >>| >> | >>| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >>| >> | >>| >> 1. The abstract contains references. The documents should | >>| >be specified | >>| >> by name since the abstract can be excerpted. | >>| >> | >>| >> 2. Line 323 over 72 chars. | >>| >> | >>| >> Line 323 length is 74 | >>| >> Routing in IS-IS", | >>| >draft-ietf-isis-wg-multi-topology-03.txt, | >>| >> April | >>| >> | >>| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. | >>| >> | >>| > | >>| > | >>| >-- | >>| >Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 21:43:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03589 for ; Mon, 2 Jun 2003 21:43:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531a1B10592; Mon, 2 Jun 2003 21:36:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531ZIB10550 for ; Mon, 2 Jun 2003 21:35:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03015 for ; Mon, 2 Jun 2003 21:35:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0g3-0000bE-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 21:33:27 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19N0g2-0000bA-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 21:33:26 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 2968C811CED; Mon, 2 Jun 2003 18:35:13 -0700 (PDT) To: prz@net4u.ch Cc: Jeff Learman , Hannes Gredler , philip.christian@christiantena.co.uk, isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational In-reply-to: Mail from Tony Przygienda dated Mon, 02 Jun 2003 22:26:04 +0200 <3EDBB2DC.3050803@net4u.ch> From: Naiming Shen Message-Id: <20030603013513.2968C811CED@prattle.redback.com> Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Jun 2003 18:35:13 -0700 yes, this(MT requires to form adj with neighbors) is only meaningful with point-to-multipoint interfaces. over p2p, we are saying no need to setup adj if not matching. but on a LAN, we need to have a DR. we can have some choices: - don't allow any protocol family to mix, any topology to mix - to have a seperate DR for each level/address-family/topology - to share the same DR within the level, always setup adjacency with everyone on the LAN to elect a stable DR, but label the adjacency useable or unusable base on the address-family and/or topology sets. announce or don't announce the adjacency in LSP accordingly. as long as a system performs backlink checks in spf computation, this scheme should work just fine. in MT draft/implementation, we thought the first solution is not acceptable, the second one is too messy, the last one works and rather easy to do. we realized that this is not a MT only property, but MT is the first one to advocate this within ISIS, and i don't see anything wrong with that. thanks. ] Jeff Learman wrote: ] ] >Hannes, what you say is correct, but Philip's point concerned ] >IPV4 vs IPV6, not common subnet addressing (a very closely related ] >issue). ] > ] >If A supports only IPV4 and B supports only IPV6, then there's no ] >way one can forward traffic to the other. So the question is, why ] >should they form an adjacency? My answer is: so that either of them ] >can be elected DR and generate pseudonode LSPs. However, this is ] >a fairly complex subject and I'm not at all certain that my proposition ] >is the best solution. Rather, it's food for thought. ] > ] > ] yepp, as far I remember the problem was that you have to form adjacencies ] on Ether to everyone (if you're DR) since otherwise you'll end up with a ] partionened ] ether and old-style devices not understanding what possibly went wrong ] ] thanks ] ] - tony ] ] > ] > ] ] ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 2 21:44:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03627 for ; Mon, 2 Jun 2003 21:44:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531Z5B10530; Mon, 2 Jun 2003 21:35:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531Y9B10482 for ; Mon, 2 Jun 2003 21:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02988 for ; Mon, 2 Jun 2003 21:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0ew-0000ai-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 21:32:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19N0ew-0000ae-00 for isis-wg@ietf.org; Mon, 02 Jun 2003 21:32:18 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19N0gd-000FFB-00; Tue, 03 Jun 2003 01:34:03 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <126859914922.20030602183334@psg.com> To: "Tony Li" CC: prz@xebeo.com, isis-wg@ietf.org Subject: Re: [Isis-wg] Tags In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 18:33:34 -0700 Content-Transfer-Encoding: 7bit Tony, > I'm not seeing a big win with 64 bits, but can be convinced. same here > By local & global scoping, I was suggesting that we divide the > range to cover both globally well-known values and good, this would help enforce their use as tags > also have > locally defined/vendor defined values. locally defined would be reasonable. how do you see vendor-defined ones being used? (remembering the discussion on vendor-specific tlvs...) would there be some structure inside the tag? Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 00:53:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07366 for ; Tue, 3 Jun 2003 00:53:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h534nZB24663; Tue, 3 Jun 2003 00:49:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h534mNB24570 for ; Tue, 3 Jun 2003 00:48:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07168; Tue, 3 Jun 2003 00:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N3gv-0001ai-00; Tue, 03 Jun 2003 00:46:33 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19N3gu-0001aH-00; Tue, 03 Jun 2003 00:46:32 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1D8823446D; Mon, 2 Jun 2003 21:02:41 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h534lhYB012823; Mon, 2 Jun 2003 21:47:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] RE: Comments on Message-ID: Thread-Topic: [Isis-wg] RE: Comments on Thread-Index: AcMpcix4hHkYN4+bSz2XGX4wFZDV0wAF9trQ From: "Tony Li" To: "Alex Zinin" , Cc: "Routing Area Directorate" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h534mNB24571 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 2 Jun 2003 21:47:43 -0700 Content-Transfer-Encoding: 8bit Let me respond to all of Alex's comments at once... How do I see vendor defined tags being used? I see them being used for experimental purposes, for shipping some new functionality before the implementation is wholly stable. As with any experimental object, I would hope that it would eventually be documented and become standardized. Just so we don't have to play proprietary IGP games yet again. | I-1. Tag TLVs introduced as any-size opaque transport containers, | such inflatable "goodie-bags" with practically no internal | structure (except for n x 32, or n x 64) where one can find | tags, but also "all kind of nice proprietary things". I submit to you that almost any experimental TLV can be used for this purpose, or any obsolete TLV value, or any hijacked TLV could be used fairly safely. So I don't believe that even if you eliminated this proposal, you would deter anyone from including Finnegan's Wake in the slightest. The issue that I have with using this (or any TLV) for such fun is that it's basically dishonest and unnecessarily so. If folks feel the need to carry A Tale of Two Cities in their IGP, well, I'm not going to stop them, but please, let's allocate some intelligent and opaque TLV so that we all realize that this is someone's private sandbox. That said, that doesn't seem like an issue that should deter this proposal. | I-2. The problem of distributing 2547-related attributes addressed | by introduction of the n x 64-bit opaque TLV, called 'tag'. | Why are we overloading the notion of tag from the | very beginning? | Why not have a separate TLV and a proper spec for this? Or, why not just explicitly allocate global tag values for 2547 attributes? I have no issue with this (above and beyond my general distaste for 2547). Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 05:50:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24950 for ; Tue, 3 Jun 2003 05:50:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539iHB27684; Tue, 3 Jun 2003 05:44:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539hdB27593 for ; Tue, 3 Jun 2003 05:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24736; Tue, 3 Jun 2003 05:43:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8Ie-0003Uv-00; Tue, 03 Jun 2003 05:41:48 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8Id-0003Us-00; Tue, 03 Jun 2003 05:41:47 -0400 Received: from net4u.ch (zux006-036-016.adsl.green.ch [81.6.36.16]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h539iNf1031402; Tue, 3 Jun 2003 11:44:23 +0200 Message-ID: <3EDC6DC0.60801@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Alex Zinin , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/related; boundary="------------090805040203010701040706" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:43:28 +0200 --------------090805040203010701040706 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Li wrote: > >Let me respond to all of Alex's comments at once... > >How do I see vendor defined tags being used? I see them being used >for experimental purposes, for shipping some new functionality before >the implementation is wholly stable. As with any experimental object, >I would hope that it would eventually be documented and become >standardized. Just so we don't have to play proprietary IGP games yet >again. > agreed > > >| I-1. Tag TLVs introduced as any-size opaque transport containers, >| such inflatable "goodie-bags" with practically no internal >| structure (except for n x 32, or n x 64) where one can find >| tags, but also "all kind of nice proprietary things". > > >I submit to you that almost any experimental TLV can be used for this >purpose, or any obsolete TLV value, or any hijacked TLV could be used >fairly safely. So I don't believe that even if you eliminated this >proposal, you would deter anyone from including Finnegan's Wake in the >slightest. > >The issue that I have with using this (or any TLV) for such fun is that >it's basically dishonest and unnecessarily so. If folks feel the >need to carry A Tale of Two Cities in their IGP, well, I'm not going >to stop them, but please, let's allocate some intelligent and opaque >TLV so that we all realize that this is someone's private sandbox. > >That said, that doesn't seem like an issue that should deter this >proposal. > agreed > > >| I-2. The problem of distributing 2547-related attributes addressed >| by introduction of the n x 64-bit opaque TLV, called 'tag'. >| Why are we overloading the notion of tag from the >| very beginning? >| Why not have a separate TLV and a proper spec for this? > > >Or, why not just explicitly allocate global tag values for 2547 >attributes? >I have no issue with this (above and beyond my general distaste for >2547). > > > oops, even you, Brutus ;-) Can we agree here on e.g.: 1) let's the 32+64 go, not worth the energy for little damage done. Decouple the two and that's it. Yes, it's tad of more implementation code but it's better than waste 2 years chewing on it. And by then, it's deployed anyway so you end up documenting it no matter what we came up with as 'better' solution. 2) introduce 2-3 bits in front of tag to structure it (albeit we have deployments, I think Cisco/JNPR would swallow that one). But, then, how would we fit EXTCOMMs that are 64bits into 64bits ? 3) Put a section in describing that in misconfiguration and using the tag for supressing prefixes in SPF, blackholes may result. 3) Put a section in that any tag that's supposed to be understood globally and influence SPF must be brought to the group thanks - tony > > --------------090805040203010701040706-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 05:54:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25028 for ; Tue, 3 Jun 2003 05:54:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539l2B27873; Tue, 3 Jun 2003 05:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539k8B27805 for ; Tue, 3 Jun 2003 05:46:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24795 for ; Tue, 3 Jun 2003 05:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8L2-0003Wa-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 05:44:16 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8L1-0003WX-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 05:44:16 -0400 Received: from net4u.ch (zux006-036-016.adsl.green.ch [81.6.36.16]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h539kmf1031872; Tue, 3 Jun 2003 11:46:48 +0200 Message-ID: <3EDC6E51.7000009@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naiming Shen CC: Jeff Learman , Hannes Gredler , philip.christian@christiantena.co.uk, isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational References: <20030603013513.2968C811CED@prattle.redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:45:53 +0200 Content-Transfer-Encoding: 7bit Naiming Shen wrote: >yes, this(MT requires to form adj with neighbors) is only meaningful >with point-to-multipoint interfaces. over p2p, we are saying no need >to setup adj if not matching. > >but on a LAN, we need to have a DR. we can have some choices: > > - don't allow any protocol family to mix, any topology to mix > > - to have a seperate DR for each level/address-family/topology > > - to share the same DR within the level, always setup adjacency > with everyone on the LAN to elect a stable DR, but label the > adjacency useable or unusable base on the address-family and/or > topology sets. announce or don't announce the adjacency in LSP > accordingly. as long as a system performs backlink checks in > spf computation, this scheme should work just fine. > >in MT draft/implementation, we thought the first solution is not >acceptable, the second one is too messy, the last one works and >rather easy to do. we realized that this is not a MT only property, >but MT is the first one to advocate this within ISIS, and i don't >see anything wrong with that. >b > from my memory when we wrote/discussed this thing I agree with Naiming ... -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 06:07:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25290 for ; Tue, 3 Jun 2003 06:07:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53A2AB28750; Tue, 3 Jun 2003 06:02:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53A1cB28713 for ; Tue, 3 Jun 2003 06:01:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25187 for ; Tue, 3 Jun 2003 06:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8a2-0003dJ-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 05:59:46 -0400 Received: from gw.xebeo.com ([204.192.44.242] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19N8a1-0003d8-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 05:59:45 -0400 Received: (qmail 7077 invoked from network); 3 Jun 2003 10:01:02 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 3 Jun 2003 10:01:02 -0000 Message-ID: <3EDC71DC.9070301@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on References: <3859276824.20030602182256@psg.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 12:01:00 +0200 Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Tony, Acee, et al. > >I think I should clarify some points here, specifically what I am >and am not concerned with and why. > >What I do NOT have a problem with (non-issues): > >NI-1. The opaque nature of a route tag as an integer attached > to a route > ok > >NI-2. Presence of a 32-bit and a 64-bit tag simultaneously if > there is a real reason for this. > the reason may be existing implementaions and/or deployment. > >NI-3. Even more than one tag, as long as they are used as _tags_, > though I can't see how more than 2 or 3 tags would be > useful. > you don't have to, people will find it out themselves or othrewise there will be never more than 3 tags around. > >However, what concerns me is (issues with discussions, please >feel free to comment): > >I-1. Tag TLVs introduced as any-size opaque transport containers, > such inflatable "goodie-bags" with practically no internal > structure (except for n x 32, or n x 64) where one can find > tags, but also "all kind of nice proprietary things". > > Is there a risk that these TLVs will be used to carry "stuff" > around? Reviewing the thread, seems that Acee, Tony P. and I > agree that this is possible: > > "...yes, you could send in 64 bit tags Finnegan's Wake up to > couple hundred bytes per prefix if you really want to..." > > What's the risk that this will happen? What is the risk that more > than one vendor will do that? Is this dangerous? Are we going to > see collisions among vendors in the field? Plus all arguments we > have seen against vendor-specific extensions during the > discussion on experimental TLVs are applicable (issues with > interop, security, changes in proto dynamics, lack of community > review, etc.) > not again. There are plenty of things in OSPF/ISIS I can misuse as 'hidden communicaiton channel'. And we agreed that even if SPF is influenced by this tag, you can only blackhole. Yes, the possibilites to kill oneself deserves a mention in the draft but otherwise it's just a pseudo-exercise in 'home-protocol-security'. You 're not protecting anyone from anything by restricting everyting to a single 32 bits tag. > > It seems that the WG needs to consider these arguments. > >I-2. The problem of distributing 2547-related attributes addressed > by introduction of the n x 64-bit opaque TLV, called 'tag'. > Why are we overloading the notion of tag from the very beginning? > Why not have a separate TLV and a proper spec for this? > Yes, we can have another draft, taking another sub-TLV point specifically 2547. What's the difference of that beside having some additional encoding rules that makes no difference in deployment behavior ? Actually, the more I think about it, the more I come to the conclusion that we should just pick up the EXTCOMM structure for those 64-bit tags and reserve the same LOW types for the same purposes. > > This goes hand in hand with the question of why we need another > tag. If we assume that the right answer to transportation of the > 2547 attributes is a separate TLV with a proper specification of > what is put there and how to act on it, then we need to answer > the question "do we need the second tag?" If we read the draft as > it stands, with the main application being route "color" and > control over prefix distribution, the second tag does not seem > necessary. > > Also, the size of the tag (8 octets) raises the risk of "stuff" > being put into it, though it is admittedly much lower than the > risk introduced by I-1 > what 'risks' of what 'stuff' and what 'lower risk' ? I hope you don't start to argue in such vague terms without any hard data to back it up. Otherwise I fear the next draft we discuss will bear the danger of weapons of mass desctruction. Sorry for the sarcasm but this is really not going anywhere fast. > >To comment on some points Tony P. brought up (those not implicitly >addressed above): > >1. Why we should know what every tag means? > > I don't believe we should (see NI-1). > agreed, however if everybody wants everybody interoperating on a specific tag value, a draft/RFC will be almost a must. > > On the other hand, if the document intends to say that one of > the applications of the tag is to control route distribution, > it should request that compliant implementations support > tag-based prefix filtering. Otherwise compliance to the spec > will not mean anything to the SP who want to actually control > prefix distribution. > not again, you can't force people to implement node-specific things. Maybe they have high-end nodes that allow policies and low-end that don't. Stop trying to mandate the internals of implementations. > >2. What about OSPF Opaque LSAs and BGP Extended Communities? > > It seems to me that the difference between them and the current tag > proposal is in the level at which opaqueness is introduced and > presence of the internal structure. > > > Regular BGP communities (RFC1997) are constructed as a set of one > or more 32-bit values, which seems very close to the description of > the 32-bit tag TLV in the draft. The difference is in the fact that > some internal structure is provided at least for admin assignment, > and that some values are reserved and defined as well-known, with > well-defined behavior, which enforces their use as tags. > > Extended communities are also different, since each ext community > is encoded as Type/Value couple, with internal structure specific > to a type, sub-types allocated by IANA, and fixed-length values. > > ok, so let's make the 64bits just like EXTCOMMs - tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 06:29:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25807 for ; Tue, 3 Jun 2003 06:29:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53AQ8B30679; Tue, 3 Jun 2003 06:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53APgB30656 for ; Tue, 3 Jun 2003 06:25:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25696 for ; Tue, 3 Jun 2003 06:25:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8xJ-0003nG-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 06:23:49 -0400 Received: from web21508.mail.yahoo.com ([66.163.169.19]) by ietf-mx with smtp (Exim 4.12) id 19N8xI-0003nA-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 06:23:49 -0400 Message-ID: <20030603102536.20015.qmail@web21508.mail.yahoo.com> Received: from [149.254.120.136] by web21508.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 11:25:36 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational To: Jeff Learman Cc: prz@net4u.ch, isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030602184847.01e88b98@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 11:25:36 +0100 (BST) Content-Transfer-Encoding: 8bit Actually there is a simple solution. A DIS election per protocol. This is what we did for the autoencap and it works really well. I thought that maybe it would be too radical for the IPv6 RFC, but given that it works, maybe I should be pushing for it. Basically it is no change for single protocol routers (except that they reject an adjacency with a neighbour that doesn't support their protocol). However a dual router has a DIS election process per protocol. It makes a pseudonode if it is the highest priority either for IPv4 capable routers, or if it is the highest priority for IPv6 capable routers. Sometimes you get two DISs on the LAN, but that doesn't cause any problems. It does guarantee that everyone gets advertised by the LSPs either from one DIS or the other. It also works for three or more protocols. Maybe this would be better for the MT folks as well. Philip --- Jeff Learman wrote: > > This is one bad case. It gets a little more > complicated when > there are 3 or more protocols involved, and the > solutions aren't > quite as simple. There might be another bad case > for 2 protocols, > but I'll have to think about it. > > The topology is illegal for 1195, but is it illegal > for MT? > > Regards, > Jeff > > At 06:30 PM 6/2/2003, Philip Christian wrote: > >I think that this is the specific scenario that > >becomes broken if IPv4 and IPv6 nodes don't have an > >adjacency. > > > >The number above the node is the priority. > > > > 3 1 2 > >+----+ +----+ +-----+ > >| v4 | | v6 | | 4/6 | > >+--+-+ +--+-+ +-+---+ > > | | | > > -+-------+------+- > > LAN > > > >In this case the v6 node sees the higher priority > of > >the 4/6 node and so doesn't make a pseudonode. > > > >The 4/6 node sees the v4 node and so doesn't make a > >pseudonode. > > > >The v4 node sees only the 4/6 node and so makes a > >pseudonode, but only includes the 4/6 node as > >connected to the pseudonode. > > > >Thus, another IS viewing the LAN from afar will > think > >that the v6 node is not connected and so will not > plot > >a route through it, as it isn't included in the > >pseudonode LSP. > > > >Without autoencap you could use this topology, but > >only very carefully. > > > >You would have to make sure that no IPv6 > destinations > >lie beyond the v4 node, and that no IPv4 > destinations > >lie beyond the v6 node. In this way you can > guarantee > >that SPF will never send an IPv4 packet through the > v6 > >node and vice versa, as all v4 destinations are > >through the 4/6 node. > > > >On this particular point, an adjacency rule such as > >G.7712s does stop a usable route being formed where > >otherwise it would be formed. The topology is > however > >illegal under RFC 1195 and one would be ill advised > to > >use it. Many vendors won't implementations won't > work > >in this scenario anyway. > > > >If you set the dual node higher than the others > then > >it works because you get a single pseudonode > declaring > >adjacencies to all others. > > > >If you set the dual node lower than the others then > it > >works because you get two pseudonodes both > declaring > >an adjacency to the dual. > > > >It only breaks if the dual node is higher than all > v4 > >nodes, but lower than a v6 node, or the other way > >around. > > > >Philip > > > >__________________________________________________ > >Yahoo! Plus - For a better Internet experience > >http://uk.promotions.yahoo.com/yplus/yoffer.html > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 10:03:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05052 for ; Tue, 3 Jun 2003 10:03:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DtLB16099; Tue, 3 Jun 2003 09:55:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DsOB16030 for ; Tue, 3 Jun 2003 09:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04538 for ; Tue, 3 Jun 2003 09:54:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCDI-0006BG-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 09:52:32 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19NCDH-0006Ai-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 09:52:31 -0400 Message-ID: From: Jeff Parker To: "'Naiming Shen'" Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 09:53:24 -0400 > - to share the same DR within the level, always setup adjacency > with everyone on the LAN to elect a stable DR, but label the > adjacency useable or unusable base on the address-family and/or > topology sets. announce or don't announce the adjacency in LSP > accordingly. as long as a system performs backlink checks in > spf computation, this scheme should work just fine. Sharing my ignorance again, I'm not sure I understand this. Assume that we have three routers: A IPv4 & IP v6 B IPv4 C IPv6 Assume A winds up being DIS. B forms adjacency with only A. Advertises link to PNode A forms adjacency with B and C. A's PNode shows link to A, B, C. C forms adjacency with only A. Advertises link to PNode Running the SPF, it isn't enough to look at links: they should all be there. Don't I need to check the protocol supported bits in the LSPs as well? - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 10:15:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06491 for ; Tue, 3 Jun 2003 10:15:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53E68B16736; Tue, 3 Jun 2003 10:06:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53E4TB16632 for ; Tue, 3 Jun 2003 10:04:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05167 for ; Tue, 3 Jun 2003 10:04:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCN3-0006IB-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:02:37 -0400 Received: from web21510.mail.yahoo.com ([66.163.169.59]) by ietf-mx with smtp (Exim 4.12) id 19NCN2-0006I8-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:02:36 -0400 Message-ID: <20030603140423.57307.qmail@web21510.mail.yahoo.com> Received: from [149.254.120.136] by web21510.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 15:04:23 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational To: Jeff Parker , "'Naiming Shen'" Cc: isis-wg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 15:04:23 +0100 (BST) Content-Transfer-Encoding: 8bit Autoencap only works because SPF doesn't consider protocol supported. Some people don't agree with this, but hey, I didn't write RFC 1195. I just took advantage of that clause. The example you cite works because the dual node is the highest priority. If the dual node is the lowest priority it also works. If it is between the two then things mess up. Philip --- Jeff Parker wrote: > > > - to share the same DR within the level, always > setup adjacency > > with everyone on the LAN to elect a stable DR, > but label the > > adjacency useable or unusable base on the > address-family and/or > > topology sets. announce or don't announce the > adjacency in LSP > > accordingly. as long as a system performs > backlink checks in > > spf computation, this scheme should work just > fine. > > Sharing my ignorance again, I'm not sure I > understand this. > > Assume that we have three routers: > > A IPv4 & IP v6 > B IPv4 > C IPv6 > > Assume A winds up being DIS. > B forms adjacency with only A. Advertises link to > PNode > A forms adjacency with B and C. A's PNode shows > link to A, B, C. > C forms adjacency with only A. Advertises link to > PNode > > Running the SPF, it isn't enough to look at links: > they > should all be there. Don't I need to check the > protocol > supported bits in the LSPs as well? > > - jeff parker > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 11:03:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08251 for ; Tue, 3 Jun 2003 11:03:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EsHB21455; Tue, 3 Jun 2003 10:54:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53ErdB21411 for ; Tue, 3 Jun 2003 10:53:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07825 for ; Tue, 3 Jun 2003 10:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ND8b-0006iM-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:51:45 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19ND8a-0006iA-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:51:44 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h53EqN3I012890; Tue, 3 Jun 2003 07:52:24 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-21.cisco.com [10.82.224.21]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACO98086; Tue, 3 Jun 2003 07:52:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20030603104509.01e86118@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational Cc: "'Naiming Shen'" , isis-wg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 10:52:19 -0400 Right, Jeff -- as long as everyone agrees who the DIS is, no problem. What if A and B elect B, but C elects A? B gets left out of the pseudonode. For MT, I believe all nodes are required to check protocols supported. This is in contrast with Autoencap and 1195. For 1195, there was no need to check protocols supported, instead deployment rules were used to avoid routes that wouldn't work. For Autoencap, it's necessary for all nodes to follow the 1195 rules and let nodes at the boundaries of actual connectivity do the encapsulation. Philip, isn't this another conflict between MT and Autoencap? Jeff At 09:53 AM 6/3/2003, Jeff Parker wrote: > >> - to share the same DR within the level, always setup adjacency >> with everyone on the LAN to elect a stable DR, but label the >> adjacency useable or unusable base on the address-family and/or >> topology sets. announce or don't announce the adjacency in LSP >> accordingly. as long as a system performs backlink checks in >> spf computation, this scheme should work just fine. > >Sharing my ignorance again, I'm not sure I understand this. > >Assume that we have three routers: > > A IPv4 & IP v6 > B IPv4 > C IPv6 > >Assume A winds up being DIS. >B forms adjacency with only A. Advertises link to PNode >A forms adjacency with B and C. A's PNode shows link to A, B, C. >C forms adjacency with only A. Advertises link to PNode > >Running the SPF, it isn't enough to look at links: they >should all be there. Don't I need to check the protocol >supported bits in the LSPs as well? > >- jeff parker >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 11:05:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08380 for ; Tue, 3 Jun 2003 11:05:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53F1EB21970; Tue, 3 Jun 2003 11:01:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53F0AB21848 for ; Tue, 3 Jun 2003 11:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08083 for ; Tue, 3 Jun 2003 11:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDEu-0006mL-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:58:16 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19NDEt-0006lx-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 10:58:15 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h53ExKdd020258; Tue, 3 Jun 2003 10:59:20 -0400 (EDT) (envelope-from dang@nexthop.com) Received: from marvin.nexthop.com (dang.nexthop.com [65.247.36.29]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h53ExD8o020241; Tue, 3 Jun 2003 10:59:13 -0400 (EDT) (envelope-from dang@nexthop.com) Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational From: Daniel Gryniewicz To: philip.christian@christiantena.co.uk Cc: prz@net4u.ch, Jeff Learman , isis-wg@ietf.org In-Reply-To: <20030602223015.49378.qmail@web21502.mail.yahoo.com> References: <20030602223015.49378.qmail@web21502.mail.yahoo.com> Content-Type: text/plain Organization: Nexthop Technologies Message-Id: <1054652348.9026.5.camel@marvin.nexthop.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: 03 Jun 2003 10:59:08 -0400 Content-Transfer-Encoding: 7bit I may be missing something, but if you have *any* v6 nodes only reachable via the v4 node, then they are cut off, because the v4 node cannot forward v6 packets to them. That's why it's a v4 node, right? Nothing you do in terms of DIS election will fix the fact that they are not reachable. However, if you fix the DIS election, then they will *look* reachable to the rest of the domain, resulting in black holed packets, rather than in unreachable destinations. Mixing address families in the domain is extremely problematic unless you have a base that everyone speaks. Daniel On Mon, 2003-06-02 at 18:30, Philip Christian wrote: > I think that this is the specific scenario that > becomes broken if IPv4 and IPv6 nodes don't have an > adjacency. > > The number above the node is the priority. > > 3 1 2 > +----+ +----+ +-----+ > | v4 | | v6 | | 4/6 | > +--+-+ +--+-+ +-+---+ > | | | > -+-------+------+- > LAN > > In this case the v6 node sees the higher priority of > the 4/6 node and so doesn't make a pseudonode. > > The 4/6 node sees the v4 node and so doesn't make a > pseudonode. > > The v4 node sees only the 4/6 node and so makes a > pseudonode, but only includes the 4/6 node as > connected to the pseudonode. > > Thus, another IS viewing the LAN from afar will think > that the v6 node is not connected and so will not plot > a route through it, as it isn't included in the > pseudonode LSP. > > Without autoencap you could use this topology, but > only very carefully. > > You would have to make sure that no IPv6 destinations > lie beyond the v4 node, and that no IPv4 destinations > lie beyond the v6 node. In this way you can guarantee > that SPF will never send an IPv4 packet through the v6 > node and vice versa, as all v4 destinations are > through the 4/6 node. > > On this particular point, an adjacency rule such as > G.7712s does stop a usable route being formed where > otherwise it would be formed. The topology is however > illegal under RFC 1195 and one would be ill advised to > use it. Many vendors won't implementations won't work > in this scenario anyway. > > If you set the dual node higher than the others then > it works because you get a single pseudonode declaring > adjacencies to all others. > > If you set the dual node lower than the others then it > works because you get two pseudonodes both declaring > an adjacency to the dual. > > It only breaks if the dual node is higher than all v4 > nodes, but lower than a v6 node, or the other way > around. > > Philip > > __________________________________________________ > Yahoo! Plus - For a better Internet experience > http://uk.promotions.yahoo.com/yplus/yoffer.html > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 11:20:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09205 for ; Tue, 3 Jun 2003 11:20:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FDfB23629; Tue, 3 Jun 2003 11:13:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FCPB23531 for ; Tue, 3 Jun 2003 11:12:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08549 for ; Tue, 3 Jun 2003 11:12:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDQq-0006tD-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:10:36 -0400 Received: from web21511.mail.yahoo.com ([66.163.169.50]) by ietf-mx with smtp (Exim 4.12) id 19NDQp-0006tA-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:10:36 -0400 Message-ID: <20030603151223.95190.qmail@web21511.mail.yahoo.com> Received: from [149.254.120.136] by web21511.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 16:12:23 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational To: Jeff Learman , Jeff Parker Cc: "'Naiming Shen'" , isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030603104509.01e86118@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 16:12:23 +0100 (BST) Content-Transfer-Encoding: 8bit > > For MT, I believe all nodes are required to check > protocols > supported where does it say that ? MT is required to have multiple SPFs, each that limits itself to an MT. Nothing to do with protocols supported TLV. MT and autoencap together is actually really powerful. You can upgrade only a few nodes to route IPv6, which would normally be contrary to RFC 1195, but then you can assign an MT to those nodes and thus run a separate SPF for IPv6. Then you can use autoencap to get rid of the IPv4 at a later time when you want to put IPv6 only routers in. Philip __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 11:45:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10933 for ; Tue, 3 Jun 2003 11:45:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FeTB26570; Tue, 3 Jun 2003 11:40:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FdiB26443 for ; Tue, 3 Jun 2003 11:39:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10278 for ; Tue, 3 Jun 2003 11:39:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDrH-0007JG-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:37:55 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19NDrG-0007IN-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:37:54 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h53Fd8Oo022190; Tue, 3 Jun 2003 08:39:08 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-21.cisco.com [10.82.224.21]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACP10613; Tue, 3 Jun 2003 08:39:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20030603112335.01ea90e0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Daniel Gryniewicz From: Jeff Learman Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: philip.christian@christiantena.co.uk, prz@net4u.ch, isis-wg@ietf.org In-Reply-To: <1054652348.9026.5.camel@marvin.nexthop.com> References: <20030602223015.49378.qmail@web21502.mail.yahoo.com> <20030602223015.49378.qmail@web21502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:36:47 -0400 At 10:59 AM 6/3/2003, Daniel Gryniewicz wrote: >I may be missing something, but if you have *any* v6 nodes only >reachable via the v4 node, then they are cut off, because the v4 node >cannot forward v6 packets to them. Right. So, either (a) don't do that, or (b) use Auto-encap. > That's why it's a v4 node, right? >Nothing you do in terms of DIS election will fix the fact that they are >not reachable. However, if you fix the DIS election, then they will >*look* reachable to the rest of the domain, resulting in black holed >packets, rather than in unreachable destinations. >Mixing address families in the domain is extremely problematic unless >you have a base that everyone speaks. This is a much more general statement that your example supports. It's true that it's problematic, but mostly because 1195 chose not to go there. It could have been solved very simply with different deployment rules and a requirement to check protocols-supported and run multiple SPFs. But 1195 didn't, and so any attempt to deal with topologies that violate 1195 deployment rules will require new standards and will involve backwards compatibility issues, and will be problematic as you say. However, I believe that the requirement that all routers support a common data protocol isn't sufficient to deal with existing and upcoming challenges, and isn't necessary to solve the problems either. It does simplify things a lot, but doesn't cover existing cases like SONET management networks, and it doesn't facilitate migrating from one protocol as the "lingua franca" to a different one (because all nodes must support the new protocol before switching over, instead of a gradual and natural transition.) Just my $0.02. Jeff >Daniel > >On Mon, 2003-06-02 at 18:30, Philip Christian wrote: >> I think that this is the specific scenario that >> becomes broken if IPv4 and IPv6 nodes don't have an >> adjacency. >> >> The number above the node is the priority. >> >> 3 1 2 >> +----+ +----+ +-----+ >> | v4 | | v6 | | 4/6 | >> +--+-+ +--+-+ +-+---+ >> | | | >> -+-------+------+- >> LAN >> >> In this case the v6 node sees the higher priority of >> the 4/6 node and so doesn't make a pseudonode. >> >> The 4/6 node sees the v4 node and so doesn't make a >> pseudonode. >> >> The v4 node sees only the 4/6 node and so makes a >> pseudonode, but only includes the 4/6 node as >> connected to the pseudonode. >> >> Thus, another IS viewing the LAN from afar will think >> that the v6 node is not connected and so will not plot >> a route through it, as it isn't included in the >> pseudonode LSP. >> >> Without autoencap you could use this topology, but >> only very carefully. >> >> You would have to make sure that no IPv6 destinations >> lie beyond the v4 node, and that no IPv4 destinations >> lie beyond the v6 node. In this way you can guarantee >> that SPF will never send an IPv4 packet through the v6 >> node and vice versa, as all v4 destinations are >> through the 4/6 node. >> >> On this particular point, an adjacency rule such as >> G.7712s does stop a usable route being formed where >> otherwise it would be formed. The topology is however >> illegal under RFC 1195 and one would be ill advised to >> use it. Many vendors won't implementations won't work >> in this scenario anyway. >> >> If you set the dual node higher than the others then >> it works because you get a single pseudonode declaring >> adjacencies to all others. >> >> If you set the dual node lower than the others then it >> works because you get two pseudonodes both declaring >> an adjacency to the dual. >> >> It only breaks if the dual node is higher than all v4 >> nodes, but lower than a v6 node, or the other way >> around. >> >> Philip >> >> __________________________________________________ >> Yahoo! Plus - For a better Internet experience >> http://uk.promotions.yahoo.com/yplus/yoffer.html >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 11:50:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11227 for ; Tue, 3 Jun 2003 11:50:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FkrB27005; Tue, 3 Jun 2003 11:46:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FjJB26891 for ; Tue, 3 Jun 2003 11:45:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10876 for ; Tue, 3 Jun 2003 11:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDwg-0007RG-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:43:30 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19NDwe-0007R0-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 11:43:29 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h53Fd73I021113; Tue, 3 Jun 2003 08:39:07 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-21.cisco.com [10.82.224.21]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACP10607; Tue, 3 Jun 2003 08:39:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20030603111918.01ec0480@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Jeff Learman Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational Cc: Jeff Parker , "'Naiming Shen'" , isis-wg@ietf.org In-Reply-To: <20030603151223.95190.qmail@web21511.mail.yahoo.com> References: <4.3.2.7.2.20030603104509.01e86118@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 11:39:03 -0400 Right, thanks. I forgot that the association between protocols and a topology is a configured thing. So the inconsistency is merely whether or not to form adjacencies to nodes you don't have any data protocols in common with. At 11:12 AM 6/3/2003, Philip Christian wrote: >> >> For MT, I believe all nodes are required to check >> protocols supported > >where does it say that ? > >MT is required to have multiple SPFs, each that limits >itself to an MT. Nothing to do with protocols >supported TLV. > >MT and autoencap together is actually really powerful. > You can upgrade only a few nodes to route IPv6, which >would normally be contrary to RFC 1195, but then you >can assign an MT to those nodes and thus run a >separate SPF for IPv6. Then you can use autoencap to >get rid of the IPv4 at a later time when you want to >put IPv6 only routers in. > >Philip > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 14:46:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19189 for ; Tue, 3 Jun 2003 14:46:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IgFB15599; Tue, 3 Jun 2003 14:42:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Id6B15353 for ; Tue, 3 Jun 2003 14:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18945 for ; Tue, 3 Jun 2003 14:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGem-0001ev-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 14:37:12 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 19NGel-0001es-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 14:37:11 -0400 Message-ID: <20030603183859.67722.qmail@web21502.mail.yahoo.com> Received: from [80.194.91.4] by web21502.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 19:38:59 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational To: Jeff Learman Cc: Jeff Parker , "'Naiming Shen'" , isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030603111918.01ec0480@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 19:38:59 +0100 (BST) Content-Transfer-Encoding: 8bit and a rather unnecessary inconsistency at that. In my opinion there is no need for the MT draft to state anything on the subject. So what do folks think about having one DIS election (or two if L1 and L2) per network layer protocol on multi-protocol routers? There really isn't any disadvantage other than being slightly different to what we did before. Philip --- Jeff Learman wrote: > > Right, thanks. I forgot that the association > between protocols and > a topology is a configured thing. So the > inconsistency is merely > whether or not to form adjacencies to nodes you > don't have any data > protocols in common with. > > At 11:12 AM 6/3/2003, Philip Christian wrote: > > >> > >> For MT, I believe all nodes are required to check > >> protocols supported > > > >where does it say that ? > > > >MT is required to have multiple SPFs, each that > limits > >itself to an MT. Nothing to do with protocols > >supported TLV. > > > >MT and autoencap together is actually really > powerful. > > You can upgrade only a few nodes to route IPv6, > which > >would normally be contrary to RFC 1195, but then > you > >can assign an MT to those nodes and thus run a > >separate SPF for IPv6. Then you can use autoencap > to > >get rid of the IPv4 at a later time when you want > to > >put IPv6 only routers in. > > > >Philip > > > >__________________________________________________ > >Yahoo! Plus - For a better Internet experience > >http://uk.promotions.yahoo.com/yplus/yoffer.html > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 14:57:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19585 for ; Tue, 3 Jun 2003 14:57:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ir6B16742; Tue, 3 Jun 2003 14:53:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IqDB16647 for ; Tue, 3 Jun 2003 14:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19378 for ; Tue, 3 Jun 2003 14:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGrT-0001lh-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 14:50:19 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGrS-0001le-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 14:50:18 -0400 Received: from net4u.ch (zux006-018-072.adsl.green.ch [81.6.18.72]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h53Iqkf1006763; Tue, 3 Jun 2003 20:52:47 +0200 Message-ID: <3EDCEE47.6000903@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philip.christian@christiantena.co.uk CC: Jeff Learman , Jeff Parker , "'Naiming Shen'" , isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational References: <20030603183859.67722.qmail@web21502.mail.yahoo.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 20:51:51 +0200 Content-Transfer-Encoding: 7bit Philip Christian wrote: >and a rather unnecessary inconsistency at that. In my >opinion there is no need for the MT draft to state >anything on the subject. > >So what do folks think about having one DIS election >(or two if L1 and L2) per network layer protocol on >multi-protocol routers? > >There really isn't any disadvantage other than being >slightly different to what we did before. > > > and that will interop with existing deployed routers ? I thought that they look at all the existing routers on the net and then play internal election. So if an old-style router gets on top in terms of priority, how do you teach him that he's not 'participating' in a certain protocol ? - tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 15:56:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22652 for ; Tue, 3 Jun 2003 15:56:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JqRB22974; Tue, 3 Jun 2003 15:52:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JpsB22927 for ; Tue, 3 Jun 2003 15:51:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22494; Tue, 3 Jun 2003 15:51:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHnI-0002HJ-00; Tue, 03 Jun 2003 15:50:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NHnH-0002HE-00; Tue, 03 Jun 2003 15:50:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NHov-000Bww-00; Tue, 03 Jun 2003 19:51:45 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <40925786801.20030603125126@psg.com> To: Tony Przygienda CC: Tony Li , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <3EDC6DC0.60801@net4u.ch> References: <3EDC6DC0.60801@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 12:51:26 -0700 Content-Transfer-Encoding: 7bit Tony, [...] > Can we agree here on e.g.: I would be fine with any approach that the WG agrees on and that preferably gets rid of the "generic container" problem. I do think that introducing structure and/or well-know reserved values solves this problem. Regarding the two items "3)" below ;) I think there was more to fix there, but I'll check. Alex > 1) let's the 32+64 go, not worth the energy for little damage done. > Decouple the two and that's it. Yes, it's tad of more implementation > code but it's better than waste 2 years chewing on it. And by then, > it's deployed anyway so you end up documenting it no matter what we > came up with as 'better' solution. > 2) introduce 2-3 bits in front of tag to structure it (albeit we > have deployments, I think Cisco/JNPR would swallow that one). But, > then, how would we fit EXTCOMMs that are 64bits into 64bits ? > 3) Put a section in describing that in misconfiguration and using > the tag for supressing prefixes in SPF, blackholes may result. > 3) Put a section in that any tag that's supposed to be understood > globally and influence SPF must be brought to the group > thanks > - tony >> >> _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 17:30:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25240 for ; Tue, 3 Jun 2003 17:30:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LQDB30837; Tue, 3 Jun 2003 17:26:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LPAB30809 for ; Tue, 3 Jun 2003 17:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25041; Tue, 3 Jun 2003 17:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJFV-0002vx-00; Tue, 03 Jun 2003 17:23:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NJFV-0002vu-00; Tue, 03 Jun 2003 17:23:17 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NJHC-000FSm-00; Tue, 03 Jun 2003 21:25:02 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66931382757.20030603142442@psg.com> To: "Tony Li" CC: isis-wg@ietf.org, "Routing Area Directorate" Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 14:24:42 -0700 Content-Transfer-Encoding: 7bit Tony, Thanks for your reply. Below, pls. > Let me respond to all of Alex's comments at once... > How do I see vendor defined tags being used? I see them being used > for experimental purposes, for shipping some new functionality before > the implementation is wholly stable. As with any experimental object, > I would hope that it would eventually be documented and become > standardized. Just so we don't have to play proprietary IGP games yet > again. Experimental would be good. Vendor-specific for shipping would most probably trigger a similar discussion we had on the experimental TLVs. > | I-1. Tag TLVs introduced as any-size opaque transport containers, > | such inflatable "goodie-bags" with practically no internal > | structure (except for n x 32, or n x 64) where one can find > | tags, but also "all kind of nice proprietary things". > I submit to you that almost any experimental TLV can be used for this > purpose, or any obsolete TLV value, or any hijacked TLV could be used > fairly safely. So I don't believe that even if you eliminated this > proposal, you would deter anyone from including Finnegan's Wake in the > slightest. > The issue that I have with using this (or any TLV) for such fun is that > it's basically dishonest and unnecessarily so. If folks feel the > need to carry A Tale of Two Cities in their IGP, well, I'm not going > to stop them, but please, let's allocate some intelligent and opaque > TLV so that we all realize that this is someone's private sandbox. Agreed > That said, that doesn't seem like an issue that should deter this > proposal. As long as the issues have been discussed and well-understood. I like you proposal with some well-defined tags though. > | I-2. The problem of distributing 2547-related attributes addressed > | by introduction of the n x 64-bit opaque TLV, called 'tag'. > | Why are we overloading the notion of tag from the > | very beginning? > | Why not have a separate TLV and a proper spec for this? > Or, why not just explicitly allocate global tag values for 2547 > attributes? > I have no issue with this (above and beyond my general distaste for > 2547). Yes, seems this would work well too. Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 17:42:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25686 for ; Tue, 3 Jun 2003 17:42:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LX6B31288; Tue, 3 Jun 2003 17:33:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LW9B31247 for ; Tue, 3 Jun 2003 17:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25306 for ; Tue, 3 Jun 2003 17:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJMG-00030W-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 17:30:16 -0400 Received: from web21503.mail.yahoo.com ([66.163.169.14]) by ietf-mx with smtp (Exim 4.12) id 19NJMF-00030T-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 17:30:15 -0400 Message-ID: <20030603213203.63869.qmail@web21503.mail.yahoo.com> Received: from [80.194.91.4] by web21503.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 22:32:03 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational To: prz@net4u.ch Cc: Jeff Learman , Jeff Parker , "'Naiming Shen'" , isis-wg@ietf.org In-Reply-To: <3EDCEE47.6000903@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 22:32:03 +0100 (BST) Content-Transfer-Encoding: 8bit It actually works with existing implementations really well. Let's do some scenarios. 1. v4v6_old and v4v6_new, v4v6_old is higher priority. The v4v6_new runs two elections, one for v4 capable and one for v6 capable. It looses both to the v4v6_old and so does not set up a pnode. The v4v6_old runs one election and wins it, and so makes a pnode which advertises the v4v6_new and itself in its LSP. 2. v4v6_old and v4v6_new, v4v6_new is higher priority. The v4v6_new runs two elections, one for v4 capable and one for v6 capable. It wins both and so sets up a pnode. Because it won both elections it adds both v4 capable and v6 capable to its LSP, in this case the v4v6_old, plus itself. The v4v6_old runs one election and looses it and so doesn't set up a pnode. 3. v4_old, v6_old and v4v6_new, v4_old is highest, v6_old is lowest The v4v6_new looses the v4 capable election, but wins the v6 capable election. Therefore it sets up a pnode that mentions only the v6 capable (v6_old and itself) in the pnode. The v4_old wins its election and so sets up a pnode mentioning everybody. The v6_old looses and so attaches itself to the v4_old pnode, it doesn't think that v4v6 should be DIS so that pnode fails the two way adjacency check and gets ignored by everybody. The v4v6_new lost to the v4_old so attaches itself to the v4_old pnode in its LSPs. 4. v4_old, v6_new and v4v6_new, v4_old is highest, v6_new is lowest The v4v6_new looses the v4 capable election, but wins the v6 capable election. Therefore it sets up a pnode that mentions only the v6 capable (v6_new and itself) in the pnode. The v4_old wins its election and so sets up a pnode mentioning v4v6_new and itself. It doesn't have adjacency with v6_new so doesn't mention it. The v6_new looses and so attaches itself to the v4v6_new pnode, it doesn't have adjacency with v4_old and so doesn't include it in the election. The v4v6_new lost to the v4_old so attaches itself to the v4_old pnode in its LSPs. There are too many scenarios to go through them all here, but I believe I looked at them all. They all work. In summary a dual node runs two elections. If it wins either then it sets up a pnode. The pnode mentions in its LSPs everyone that voted for it, so if it wins both it mentions all v4 capable and all v6 capable, but if it wins only the v6 election (because a v4 capable was higher priority), then it only mentions v6 capable ISs in the pnode LSPs. Philip --- Tony Przygienda wrote: > Philip Christian wrote: > > >and a rather unnecessary inconsistency at that. In > my > >opinion there is no need for the MT draft to state > >anything on the subject. > > > >So what do folks think about having one DIS > election > >(or two if L1 and L2) per network layer protocol on > >multi-protocol routers? > > > >There really isn't any disadvantage other than > being > >slightly different to what we did before. > > > > > > > and that will interop with existing deployed routers > ? I thought that > they look at all the existing routers on the net and > then play internal > election. So if an old-style router gets on top in > terms of priority, > how do you teach him that he's not 'participating' > in a certain > protocol ? > > - tony > > > > > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 17:52:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26145 for ; Tue, 3 Jun 2003 17:52:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Ln7B00407; Tue, 3 Jun 2003 17:49:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LmXB00384 for ; Tue, 3 Jun 2003 17:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25998 for ; Tue, 3 Jun 2003 17:48:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJc8-0003C8-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 17:46:40 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJc7-0003C3-00 for isis-wg@ietf.org; Tue, 03 Jun 2003 17:46:39 -0400 Received: from net4u.ch (zux006-018-072.adsl.green.ch [81.6.18.72]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h53Ln6f1008809; Tue, 3 Jun 2003 23:49:07 +0200 Message-ID: <3EDD179C.5080407@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philip.christian@christiantena.co.uk CC: Jeff Learman , Jeff Parker , "'Naiming Shen'" , isis-wg@ietf.org Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational References: <20030603213203.63869.qmail@web21503.mail.yahoo.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 23:48:12 +0200 Content-Transfer-Encoding: 7bit Philip Christian wrote: >It actually works with existing implementations really >well. > >Let's do some scenarios. > >1. v4v6_old and v4v6_new, v4v6_old is higher priority. >The v4v6_new runs two elections, one for v4 capable >and one for v6 capable. It looses both to the >v4v6_old and so does not set up a pnode. The v4v6_old >runs one election and wins it, and so makes a pnode >which advertises the v4v6_new and itself in its LSP. > >2. v4v6_old and v4v6_new, v4v6_new is higher priority. >The v4v6_new runs two elections, one for v4 capable >and one for v6 capable. It wins both and so sets up a >pnode. Because it won both elections it adds both v4 >capable and v6 capable to its LSP, in this case the >v4v6_old, plus itself. The v4v6_old runs one election >and looses it and so doesn't set up a pnode. > >3. v4_old, v6_old and v4v6_new, v4_old is highest, >v6_old is lowest >The v4v6_new looses the v4 capable election, but wins >the v6 capable election. Therefore it sets up a pnode >that mentions only the v6 capable (v6_old and itself) >in the pnode. The v4_old wins its election and so >sets up a pnode mentioning everybody. The v6_old >looses and so attaches itself to the v4_old pnode, it >doesn't think that v4v6 should be DIS so that pnode >fails the two way adjacency check and gets ignored by >everybody. The v4v6_new lost to the v4_old so >attaches itself to the v4_old pnode in its LSPs. > >4. v4_old, v6_new and v4v6_new, v4_old is highest, >v6_new is lowest >The v4v6_new looses the v4 capable election, but wins >the v6 capable election. Therefore it sets up a pnode >that mentions only the v6 capable (v6_new and itself) >in the pnode. The v4_old wins its election and so >sets up a pnode mentioning v4v6_new and itself. It >doesn't have adjacency with v6_new so doesn't mention >it. The v6_new looses and so attaches itself to the >v4v6_new pnode, it doesn't have adjacency with v4_old >and so doesn't include it in the election. The >v4v6_new lost to the v4_old so attaches itself to the >v4_old pnode in its LSPs. > >There are too many scenarios to go through them all >here, but I believe I looked at them all. They all >work. > >In summary a dual node runs two elections. If it wins >either then it sets up a pnode. The pnode mentions in >its LSPs everyone that voted for it, so if it wins >both it mentions all v4 capable and all v6 capable, >but if it wins only the v6 election (because a v4 >capable was higher priority), then it only mentions v6 >capable ISs in the pnode LSPs. > >Philip > > ok, I tried to understand this tricky business reading your newest draft again and that will need some discussion in a smaller implementor's list to weigh the pros vs. the risk. thanks -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 3 19:26:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29863 for ; Tue, 3 Jun 2003 19:26:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53NOCB06903; Tue, 3 Jun 2003 19:24:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53NNsB06848 for ; Tue, 3 Jun 2003 19:23:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29695; Tue, 3 Jun 2003 19:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NL6S-0003sb-00; Tue, 03 Jun 2003 19:22:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NL6R-0003sX-00; Tue, 03 Jun 2003 19:22:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NL8A-000JZJ-00; Tue, 03 Jun 2003 23:23:50 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <178938506831.20030603162326@psg.com> To: Tony Przygienda CC: isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <3EDC71DC.9070301@xebeo.com> References: <3859276824.20030602182256@psg.com> <3EDC71DC.9070301@xebeo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Jun 2003 16:23:26 -0700 Content-Transfer-Encoding: 7bit Tuesday, June 3, 2003, 3:01:00 AM, Tony Przygienda wrote: ... >>I-2. The problem of distributing 2547-related attributes addressed >> by introduction of the n x 64-bit opaque TLV, called 'tag'. >> Why are we overloading the notion of tag from the very beginning? >> Why not have a separate TLV and a proper spec for this? >> > Yes, we can have another draft, taking another sub-TLV point > specifically 2547. What's the difference of that beside having some > additional encoding rules that makes no difference in deployment > behavior ? The difference with a non-structured tag would be two-fold: 1. Separate sub-TLV wouldn't be reused for other purposes 2. Its contents and associated router behavior would be clearly documented. > Actually, the more I think about it, the more I come to > the conclusion that we should just pick up the EXTCOMM structure for > those 64-bit tags and reserve the same LOW types for the same > purposes. Introducing stricture inside the tag and reserving a value for the 2547 application would have the same effect as a separate sub-TLV. >>1. Why we should know what every tag means? >> I don't believe we should (see NI-1). >> > agreed, however if everybody wants everybody interoperating on a > specific tag value, a draft/RFC will be almost a must. Agreed. >> On the other hand, if the document intends to say that one of >> the applications of the tag is to control route distribution, >> it should request that compliant implementations support >> tag-based prefix filtering. Otherwise compliance to the spec >> will not mean anything to the SP who want to actually control >> prefix distribution. >> > not again, you can't force people to implement node-specific things. > Maybe they have high-end nodes that allow policies and low-end that > don't. Stop trying to mandate the internals of implementations. I don't know why you are talking about implementation internals here, and it is interesting that I have to argue this again, while we agreed on this point before: Alex Zinin wrote: >Here's my thinking here. > >The title of the document: > > "A Policy Control Mechanism in IS-IS Using Administrative Tags" > >The abstract says: > > "This document describes an extension to the IS-IS protocol to add > operational capabilities that allow for ease of management and > control over IP prefix distribution within an IS-IS domain. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... > > This extension will provide operators with a mechanism to control IP > ^^^^^^^^^^^^^^^^^^^^^^^ > prefix distribution throughout multi-level IS-IS domains. > ^^^^^^^^^^^^^^^^^^^ > Additionally, the information can be placed in LSPs that have TLVs as > yet undefined, if this information is used to convey the same meaning > in these future TLVs as it is used in the currently defined TLVs." > >and one can definitely feel that filtering at the area boundaries is >one of the major applications of this TLV. > >However, because the document requests the compliant implementations >to only be able to insert the tag, but not filter using it at the >L1/L2 IS'es, an operator cannot expect all compliant implementations >to be useful for this function, i.e., they will need to ask if >functions outside the scope of this document are supported by specific >vendors, go into details of how they do that to make sure different >implementations can work together in a consistent way. Do you see what >I mean here? If you guys don't expect compliant implementations to actually be able 'control IP prefix distribution', then don't confuse the reader and remove hints on it in the text. If, on the other hand, SPs really want implementations of this document to be any more useful in prefix control than just flooding the TLV and displaying the value in the show command, then something like 'MUST support filtering on boundaries' would make sense in the document. Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jun 4 04:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08366 for ; Wed, 4 Jun 2003 04:53:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548nkB26502; Wed, 4 Jun 2003 04:49:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548mbB26448 for ; Wed, 4 Jun 2003 04:48:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08214; Wed, 4 Jun 2003 04:48:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTuu-0007eI-00; Wed, 04 Jun 2003 04:46:44 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19NTut-0007eD-00; Wed, 04 Jun 2003 04:46:43 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h548lKZ30989; Wed, 4 Jun 2003 10:47:20 +0200 From: Hannes Gredler To: Alex Zinin Cc: Acee Lindem , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030604084720.GA30860@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <20030530222903.GA11581@juniper.net> <44859393983.20030602182453@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44859393983.20030602182453@psg.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Jun 2003 10:47:20 +0200 On Mon, Jun 02, 2003 at 06:24:53PM -0700, Alex Zinin wrote: | Hannes, | | Are the tag and tag2 both 32-bit tags taken from the same TLV or do | you have the 64-bit tags coded/deployed also? the code that is currently in the field does support only 32-bit tags; both tags are attached either to TLV 135 and 236 [pls have a look at the attached tcpdump output]; /hannes #tcpdump -nvr subtlv2.tcpdump 19:14:07.936565 OSI, IS-IS, length: 201 hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0), pdu-type: L1 LSP lsp-id: 0000.0000.0003-00, seq: 0x0000004f, lifetime: 65533s chksum: 0x23cb (correct), PDU length: 201, L1L2 IS Area address(es) TLV #1, length: 12 Area address (length: 1): 01 Area address (length: 5): 47.0002.0001 Area address (length: 3): 49.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4, IPv6 Traffic Engineering Router ID TLV #134, length: 4 Traffic Engineering Router ID: 192.168.1.3 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 192.168.1.3 Hostname TLV #137, length: 7 Hostname: speed-1 Extended IS Reachability TLV #22, length: 17 IS Neighbor: 0000.0000.0003.02, Metric: 10, sub-TLVs present (6) IPv4 interface address: 192.168.1.1 Extended IPv4 reachability TLV #135, length: 79 IPv4 prefix: 192.168.1.0/24, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 192.168.223.224/28, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 10.0.0.4/30, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 192.168.1.3/32, Distribution: up, Metric: 0, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv6 reachability TLV #236, length: 33 IPv6 prefix: 2001:600::3/128, Distribution: up, Metric: 0, Internal, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 6 12:15:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00794 for ; Fri, 6 Jun 2003 12:15:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GCDB05975; Fri, 6 Jun 2003 12:12:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FgXB02678 for ; Fri, 6 Jun 2003 11:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28974; Fri, 6 Jun 2003 11:42:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJKW-0003Ex-00; Fri, 06 Jun 2003 11:40:36 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19OJKV-0003EZ-00; Fri, 06 Jun 2003 11:40:35 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h56Ffwi9016089; Fri, 6 Jun 2003 11:41:58 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h56FfsSj016082; Fri, 6 Jun 2003 11:41:54 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h56FfmP09840; Fri, 6 Jun 2003 11:41:48 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Alex Zinin , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030606114148.H8964@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Mon, Jun 02, 2003 at 09:47:43PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 6 Jun 2003 11:41:48 -0400 On Mon, Jun 02, 2003 at 09:47:43PM -0700, Tony Li wrote: > How do I see vendor defined tags being used? I see them being used > for experimental purposes, for shipping some new functionality before > the implementation is wholly stable. As with any experimental object, > I would hope that it would eventually be documented and become > standardized. Just so we don't have to play proprietary IGP games yet > again. Is it worth specifying a transitional mechanism to move the ID out of the "experimental" space into the ietf-consensus numbered space? > I submit to you that almost any experimental TLV can be used for this > purpose, or any obsolete TLV value, or any hijacked TLV could be used > fairly safely. My concern has been collision in the numbering space. In the BGP extended community experimental numbering space, there is no guidance as to how you should pick your experimental number. I haven't seen vendors providing a knob to set the feature's community number and thus its possible for two vendors to utilize the same number and end up causing all sorts of havoc. I don't disagree with the idea of an experimental space, but it would be nice to at least talk about namespace collisions and how we might work around them. I would also prefer an answer isn't "this hurts", "Don't do that then!". > Tony -- Jeff Haas NextHop Technologies _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 9 07:53:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29056 for ; Mon, 9 Jun 2003 07:53:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BoJB26481; Mon, 9 Jun 2003 07:50:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BjgB26288 for ; Mon, 9 Jun 2003 07:45:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28676; Mon, 9 Jun 2003 07:45:40 -0400 (EDT) Message-Id: <200306091145.HAA28676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-05.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 07:45:40 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-05.txt Pages : 6 Date : 2003-6-6 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO 10589, with extensions to support IPv4 described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specificqation only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-05.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-05.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: <2003-6-6133220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6133220.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 9 16:28:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20129 for ; Mon, 9 Jun 2003 16:28:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KOKB01144; Mon, 9 Jun 2003 16:24:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KNLB01100 for ; Mon, 9 Jun 2003 16:23:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19962; Mon, 9 Jun 2003 16:23:17 -0400 (EDT) Message-Id: <200306092023.QAA19962@ietf.org> To: IETF-Announce: ; Cc: isis-wg@ietf.org From: The IESG Reply-to: iesg@ietf.org Subject: [Isis-wg] Last Call: IS-IS Extensions in Support of Generalized MPLS to Informational RFC Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Jun 2003 16:23:17 -0400 The IESG has received a request from the IS-IS for IP Internets Working Group to consider IS-IS Extensions in Support of Generalized MPLS as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-23. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-16.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 11:09:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04834 for ; Tue, 10 Jun 2003 11:09:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AF52B29410; Tue, 10 Jun 2003 11:05:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AF26B29328 for ; Tue, 10 Jun 2003 11:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04526 for ; Tue, 10 Jun 2003 11:01:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkbN-0007EX-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 10:59:57 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19PkbM-0007ET-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 10:59:56 -0400 Received: (qmail 17013 invoked from network); 10 Jun 2003 15:11:36 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 10 Jun 2003 15:11:36 -0000 Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HG9TR600.IVS; Tue, 10 Jun 2003 11:01:54 -0400 Message-ID: <3EE5F2DD.9794A0F@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: OSPF@PEACH.EASE.LSOFT.COM CC: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Inconsistent view of routers over a LAN Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 11:01:49 -0400 Content-Transfer-Encoding: 7bit Hello, What happens if for some reason Router A can't reach Router B, but Router C can reach A & B (and vice-versa), when Router A,B,C are connected over a broadcast network or LAN. E.g. in the case for (OSPF and IS-IS) where: i) C is the DR ii) B is the DR Thanks Cheng-Yin _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 11:59:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06641 for ; Tue, 10 Jun 2003 11:59:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFtTB01606; Tue, 10 Jun 2003 11:55:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFqRB01433 for ; Tue, 10 Jun 2003 11:52:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06365 for ; Tue, 10 Jun 2003 11:52:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlOA-0007ce-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 11:50:22 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19PlO9-0007cb-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 11:50:22 -0400 Received: (qmail 1701 invoked from network); 10 Jun 2003 16:02:06 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 10 Jun 2003 16:02:06 -0000 Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HG9W3C00.KYM; Tue, 10 Jun 2003 11:52:24 -0400 Message-ID: <3EE5FEB3.156FB9E3@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mailing List CC: isis-wg@ietf.org References: <3EE5F2DD.9794A0F@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Re: Inconsistent view of routers over a LAN Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 11:52:19 -0400 Content-Transfer-Encoding: 7bit Hello, Just got some private responses, perhaps I should clarify. This is in context of an emulated LAN, and I am not looking for a fix in routing protocols. Thanks Cheng-Yin Cheng-Yin Lee wrote: > > Hello, > What happens if for some reason Router A can't reach Router B, but > Router C can reach A & B (and vice-versa), when Router A,B,C are > connected over a broadcast network or LAN. > > E.g. in the case for (OSPF and IS-IS) where: > i) C is the DR > ii) B is the DR > > Thanks > Cheng-Yin _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 12:49:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08807 for ; Tue, 10 Jun 2003 12:49:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGkVB07549; Tue, 10 Jun 2003 12:46:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGgwB07313 for ; Tue, 10 Jun 2003 12:42:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08550 for ; Tue, 10 Jun 2003 12:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmB2-0000OE-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 12:40:52 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19PmB2-0000Nq-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 12:40:52 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AGgHje006030; Tue, 10 Jun 2003 09:42:22 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-222-135.cisco.com [64.102.222.135]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADJ87941; Tue, 10 Jun 2003 09:42:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20030610122727.00b6f9b8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Cheng-Yin.Lee@alcatel.com From: Jeff Learman Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN Cc: Mailing List , isis-wg@ietf.org In-Reply-To: <3EE5FEB3.156FB9E3@alcatel.com> References: <3EE5F2DD.9794A0F@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 12:28:43 -0400 This violates the transitivity requirement stated in ISO 10589. You can't run ISIS on a subnetwork where this happens. At least, that's the theory ;) At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: >Hello, >Just got some private responses, perhaps I should clarify. >This is in context of an emulated LAN, and I am not looking for a fix in >routing protocols. > >Thanks >Cheng-Yin > >Cheng-Yin Lee wrote: >> >> Hello, >> What happens if for some reason Router A can't reach Router B, but >> Router C can reach A & B (and vice-versa), when Router A,B,C are >> connected over a broadcast network or LAN. >> >> E.g. in the case for (OSPF and IS-IS) where: >> i) C is the DR >> ii) B is the DR >> >> Thanks >> Cheng-Yin >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 14:33:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11941 for ; Tue, 10 Jun 2003 14:33:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIQEB14809; Tue, 10 Jun 2003 14:26:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIPoB14761 for ; Tue, 10 Jun 2003 14:25:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11571 for ; Tue, 10 Jun 2003 14:25:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnmY-00018i-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 14:23:42 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19PnmX-00018M-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 14:23:42 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 3907223C57; Tue, 10 Jun 2003 11:12:45 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h5AIPDYB018059; Tue, 10 Jun 2003 11:25:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Re: Inconsistent view of routers over a LAN Message-ID: Thread-Topic: [Isis-wg] Re: Inconsistent view of routers over a LAN Thread-Index: AcMvcS6+zWnZJFXHRk+TVD5ypJ7F5AADEcXA From: "Tony Li" To: "Jeff Learman" , Cc: "Mailing List" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AIPoB14762 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 11:25:13 -0700 Content-Transfer-Encoding: 8bit We should also point out that in case i) things are truly broken and in case ii) the DR will not form an adjacency with A and the protocols will be able to tell that things are broken. Tony | -----Original Message----- | From: Jeff Learman [mailto:jlearman@cisco.com] | Sent: Tuesday, June 10, 2003 9:29 AM | To: Cheng-Yin.Lee@alcatel.com | Cc: Mailing List; isis-wg@ietf.org | Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN | | | | This violates the transitivity requirement stated in ISO 10589. | You can't run ISIS on a subnetwork where this happens. | At least, that's the theory ;) | | At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: | >Hello, | >Just got some private responses, perhaps I should clarify. | >This is in context of an emulated LAN, and I am not | looking for a fix in | >routing protocols. | > | >Thanks | >Cheng-Yin | > | >Cheng-Yin Lee wrote: | >> | >> Hello, | >> What happens if for some reason Router A can't reach | Router B, but | >> Router C can reach A & B (and vice-versa), when Router A,B,C are | >> connected over a broadcast network or LAN. | >> | >> E.g. in the case for (OSPF and IS-IS) where: | >> i) C is the DR | >> ii) B is the DR | >> | >> Thanks | >> Cheng-Yin | >_______________________________________________ | >Isis-wg mailing list | >Isis-wg@ietf.org | >https://www1.ietf.org/mailman/listinfo/isis-wg | | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 16:48:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17281 for ; Tue, 10 Jun 2003 16:48:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKiHB25237; Tue, 10 Jun 2003 16:44:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKhPB25212 for ; Tue, 10 Jun 2003 16:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16975 for ; Tue, 10 Jun 2003 16:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ppvj-0001xr-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 16:41:19 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx2.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19Ppvh-0001xd-00 for isis-wg@ietf.org; Tue, 10 Jun 2003 16:41:17 -0400 Received: (qmail 14932 invoked from network); 10 Jun 2003 20:45:54 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx2.ca.alcatel.com with SMTP; 10 Jun 2003 20:45:54 -0000 Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HGA9K500.H6D; Tue, 10 Jun 2003 16:43:17 -0400 Message-ID: <3EE642E0.F617107F@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li CC: Jeff Learman , Mailing List , isis-wg@ietf.org, Acee Lindem , l2vpn@ietf.org Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 16:43:12 -0400 Content-Transfer-Encoding: 7bit Jeff, Tony, Acee, Thanks for your clarification. L2VPN WG is defining emulated LAN (and broadcast network for IP traffic) service over IP/MPLS network and some of the mechanims being defined can result in loss of communication among a subset of routers on the emulated LAN (even if all the nodes in the underlying IP/MPLS transport network are reachable). Some of the discussions have been how tolerable are routing protocols to this type of problem, if it is worth fixing some L2VPN WG mechanisms to prevent this problem, how feasible are these L2VPN solutions, are these not well-known problems ... I hope the L2VPN WG would consider these issues and requirements in the L2VPN solutions. Perhaps a more detailed understanding of how things work/don't work may help L2VPN WG develop/appreciate solutios that will work well with routers for e.g, in case of (i) below, what would an emulated LAN user observe in the routed network (is this predictable/unpredictable?) Thanks Cheng-Yin p.s I have cced l2vpn, but pls feel free to respond only to the relevant WG as is appropriate. Tony Li wrote: > > We should also point out that in case i) things are truly broken and > in case ii) the DR will not form an adjacency with A and the protocols > will be able to tell that things are broken. > > Tony > > | -----Original Message----- > | From: Jeff Learman [mailto:jlearman@cisco.com] > | Sent: Tuesday, June 10, 2003 9:29 AM > | To: Cheng-Yin.Lee@alcatel.com > | Cc: Mailing List; isis-wg@ietf.org > | Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN > | > | > | > | This violates the transitivity requirement stated in ISO 10589. > | You can't run ISIS on a subnetwork where this happens. > | At least, that's the theory ;) > | > | At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: > | >Hello, > | >Just got some private responses, perhaps I should clarify. > | >This is in context of an emulated LAN, and I am not > | looking for a fix in > | >routing protocols. > | > > | >Thanks > | >Cheng-Yin > | > > | >Cheng-Yin Lee wrote: > | >> > | >> Hello, > | >> What happens if for some reason Router A can't reach > | Router B, but > | >> Router C can reach A & B (and vice-versa), when Router A,B,C are > | >> connected over a broadcast network or LAN. > | >> > | >> E.g. in the case for (OSPF and IS-IS) where: > | >> i) C is the DR > | >> ii) B is the DR > | >> > | >> Thanks > | >> Cheng-Yin > Hi Cheng-Yin, > > What I've recommended in the past for these situations is to force > the routing protocol to view the underlying network as a P2MP > (Point-to-Multi-Point) network. Many vendors support this. For > example, in our implementation you'd simply configure: > > router ospf 1 > area 0 > interface backbone > network-type point-to-multipoint > o > o > < the rest of the OSPF config> > o > > Good Luck, > Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 17:18:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18552 for ; Tue, 10 Jun 2003 17:18:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALF8B28100; Tue, 10 Jun 2003 17:15:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALEQB28029 for ; Tue, 10 Jun 2003 17:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18224; Tue, 10 Jun 2003 17:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PqPj-0002Eo-00; Tue, 10 Jun 2003 17:12:19 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19PqPh-0002El-00; Tue, 10 Jun 2003 17:12:17 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 78EA01498EB; Tue, 10 Jun 2003 14:14:20 -0700 (PDT) To: Cheng-Yin.Lee@alcatel.com Cc: Tony Li , Jeff Learman , Mailing List , isis-wg@ietf.org, Acee Lindem , l2vpn@ietf.org Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN In-reply-to: Mail from "Cheng-Yin Lee" dated Tue, 10 Jun 2003 16:43:12 EDT <3EE642E0.F617107F@alcatel.com> From: Naiming Shen Message-Id: <20030610211420.78EA01498EB@prattle.redback.com> Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 14:14:20 -0700 i don't think l2vpn wg needs to do much. when use link-state igp in those places, ALWAYS assume it's unreliable. just use p2p. period. ] Jeff, Tony, Acee, ] Thanks for your clarification. ] L2VPN WG is defining emulated LAN (and broadcast network for IP traffic) ] service over IP/MPLS network and some of the mechanims being defined can ] result in loss of communication among a subset of routers on the ] emulated LAN (even if all the nodes in the underlying IP/MPLS transport ] network are reachable). ] Some of the discussions have been how tolerable are routing protocols to ] this type of problem, if it is worth fixing some L2VPN WG mechanisms to ] prevent this problem, how feasible are these L2VPN solutions, are these ] not well-known problems ... ] ] I hope the L2VPN WG would consider these issues and requirements in the ] L2VPN solutions. ] Perhaps a more detailed understanding of how things work/don't work may ] help L2VPN WG develop/appreciate solutios that will work well with ] routers for e.g, in case of (i) below, what would an emulated LAN user ] observe in the routed network (is this predictable/unpredictable?) ] ] Thanks ] Cheng-Yin ] p.s I have cced l2vpn, but pls feel free to respond only to the relevant ] WG as is appropriate. ] ] Tony Li wrote: ] > ] > We should also point out that in case i) things are truly broken and ] > in case ii) the DR will not form an adjacency with A and the protocols ] > will be able to tell that things are broken. ] > ] > Tony ] > ] > | -----Original Message----- ] > | From: Jeff Learman [mailto:jlearman@cisco.com] ] > | Sent: Tuesday, June 10, 2003 9:29 AM ] > | To: Cheng-Yin.Lee@alcatel.com ] > | Cc: Mailing List; isis-wg@ietf.org ] > | Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN ] > | ] > | ] > | ] > | This violates the transitivity requirement stated in ISO 10589. ] > | You can't run ISIS on a subnetwork where this happens. ] > | At least, that's the theory ;) ] > | ] > | At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: ] > | >Hello, ] > | >Just got some private responses, perhaps I should clarify. ] > | >This is in context of an emulated LAN, and I am not ] > | looking for a fix in ] > | >routing protocols. ] > | > ] > | >Thanks ] > | >Cheng-Yin ] > | > ] > | >Cheng-Yin Lee wrote: ] > | >> ] > | >> Hello, ] > | >> What happens if for some reason Router A can't reach ] > | Router B, but ] > | >> Router C can reach A & B (and vice-versa), when Router A,B,C are ] > | >> connected over a broadcast network or LAN. ] > | >> ] > | >> E.g. in the case for (OSPF and IS-IS) where: ] > | >> i) C is the DR ] > | >> ii) B is the DR ] > | >> ] > | >> Thanks ] > | >> Cheng-Yin ] ] ] > Hi Cheng-Yin, ] > ] > What I've recommended in the past for these situations is to force ] > the routing protocol to view the underlying network as a P2MP ] > (Point-to-Multi-Point) network. Many vendors support this. For ] > example, in our implementation you'd simply configure: ] > ] > router ospf 1 ] > area 0 ] > interface backbone ] > network-type point-to-multipoint ] > o ] > o ] > < the rest of the OSPF config> ] > o ] > ] > Good Luck, ] > Acee ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 10 17:21:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18636 for ; Tue, 10 Jun 2003 17:21:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALH1B28233; Tue, 10 Jun 2003 17:17:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALG6B28180 for ; Tue, 10 Jun 2003 17:16:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18300; Tue, 10 Jun 2003 17:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PqRL-0002G2-00; Tue, 10 Jun 2003 17:13:59 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19PqRK-0002Fl-00; Tue, 10 Jun 2003 17:13:58 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 8C4473443F; Tue, 10 Jun 2003 13:30:39 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h5ALFVYB022829; Tue, 10 Jun 2003 14:15:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Re: Inconsistent view of routers over a LAN Message-ID: Thread-Topic: [Isis-wg] Re: Inconsistent view of routers over a LAN Thread-Index: AcMvkPDidAYjI9EtRdCmhJaXDdRP+gAA+ppw From: "Tony Li" To: Cc: "Jeff Learman" , "Mailing List" , , "Acee Lindem" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ALG6B28181 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 14:15:31 -0700 Content-Transfer-Encoding: 8bit Folks, In particular, if there is a disconnect on a broadcast medium between two routers and neither is the DR, then the two routers will present a black hole between them. This problem has been seen before in real life and is Not Pretty. For this reason alone, I would encourage you to model any L2 solution as a number of point-to-point links. Regards, Tony | -----Original Message----- | From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] | Sent: Tuesday, June 10, 2003 1:43 PM | To: Tony Li | Cc: Jeff Learman; Mailing List; isis-wg@ietf.org; Acee | Lindem; l2vpn@ietf.org | Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN | | | Jeff, Tony, Acee, | Thanks for your clarification. | L2VPN WG is defining emulated LAN (and broadcast network | for IP traffic) | service over IP/MPLS network and some of the mechanims | being defined can | result in loss of communication among a subset of routers on the | emulated LAN (even if all the nodes in the underlying | IP/MPLS transport | network are reachable). | Some of the discussions have been how tolerable are | routing protocols to | this type of problem, if it is worth fixing some L2VPN WG | mechanisms to | prevent this problem, how feasible are these L2VPN | solutions, are these | not well-known problems ... | | I hope the L2VPN WG would consider these issues and | requirements in the | L2VPN solutions. | Perhaps a more detailed understanding of how things | work/don't work may | help L2VPN WG develop/appreciate solutios that will work well with | routers for e.g, in case of (i) below, what would an | emulated LAN user | observe in the routed network (is this predictable/unpredictable?) | | Thanks | Cheng-Yin | p.s I have cced l2vpn, but pls feel free to respond only | to the relevant | WG as is appropriate. | | Tony Li wrote: | > | > We should also point out that in case i) things are | truly broken and | > in case ii) the DR will not form an adjacency with A and | the protocols | > will be able to tell that things are broken. | > | > Tony | > | > | -----Original Message----- | > | From: Jeff Learman [mailto:jlearman@cisco.com] | > | Sent: Tuesday, June 10, 2003 9:29 AM | > | To: Cheng-Yin.Lee@alcatel.com | > | Cc: Mailing List; isis-wg@ietf.org | > | Subject: Re: [Isis-wg] Re: Inconsistent view of | routers over a LAN | > | | > | | > | | > | This violates the transitivity requirement stated | in ISO 10589. | > | You can't run ISIS on a subnetwork where this happens. | > | At least, that's the theory ;) | > | | > | At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: | > | >Hello, | > | >Just got some private responses, perhaps I should clarify. | > | >This is in context of an emulated LAN, and I am not | > | looking for a fix in | > | >routing protocols. | > | > | > | >Thanks | > | >Cheng-Yin | > | > | > | >Cheng-Yin Lee wrote: | > | >> | > | >> Hello, | > | >> What happens if for some reason Router A can't reach | > | Router B, but | > | >> Router C can reach A & B (and vice-versa), when | Router A,B,C are | > | >> connected over a broadcast network or LAN. | > | >> | > | >> E.g. in the case for (OSPF and IS-IS) where: | > | >> i) C is the DR | > | >> ii) B is the DR | > | >> | > | >> Thanks | > | >> Cheng-Yin | | | > Hi Cheng-Yin, | > | > What I've recommended in the past for these situations | is to force | > the routing protocol to view the underlying network as a P2MP | > (Point-to-Multi-Point) network. Many vendors support this. For | > example, in our implementation you'd simply configure: | > | > router ospf 1 | > area 0 | > interface backbone | > network-type point-to-multipoint | > o | > o | > < the rest of the OSPF config> | > o | > | > Good Luck, | > Acee | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jun 11 18:33:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07467 for ; Wed, 11 Jun 2003 18:33:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMUjm12145; Wed, 11 Jun 2003 18:30:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMTFm12040 for ; Wed, 11 Jun 2003 18:29:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07251 for ; Wed, 11 Jun 2003 18:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QE3f-0004if-00 for isis-wg@ietf.org; Wed, 11 Jun 2003 18:27:07 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19QE3e-0004ia-00 for isis-wg@ietf.org; Wed, 11 Jun 2003 18:27:06 -0400 Received: (qmail 26991 invoked from network); 11 Jun 2003 22:38:55 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 11 Jun 2003 22:38:55 -0000 Received: from alcatel.com ([138.120.62.63]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HGC94M00.5RB; Wed, 11 Jun 2003 18:29:10 -0400 Message-ID: <3EE7AD2E.B9773CEF@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li CC: Jeff Learman , Mailing List , isis-wg@ietf.org, Acee Lindem , l2vpn@ietf.org Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Jun 2003 18:29:02 -0400 Content-Transfer-Encoding: 7bit Tony, Naiming, Thanks for clarifying this further and providing suggestions. I would agree that it's better to use point-to-point links (or OSPF's multipoint) when there are such problems. As known, this is not a problem in a real LAN segment or emulated LAN segment, provided by a bridged LAN (bridging over real LAN segments) or bridging over circuits. As has been brought up in the OSPF/IS-IS mailing lists, it is when the emulated LAN (broadcast network) uses an approach whereby a full-meshed of communication is required and there is a requirement that every communication channel is working that this becomes a problem for routing (and for bridges too). There have been some proposals to overcome the problems in the full-meshed approach, e.g. disabling the emulated LAN when one or more connectivity loss is detected or artificially partitioning the emulated LAN, or engineer the transport network in such a way that communication failure never/rarely happens from the perspective of the user of the service (e.g. routers). More protocol mechanisms (and perhaps some heuristics) may be used to emulate a proper LAN failure, but I think it not easy to get this working (it also raises the question, is this the only compelling way), in particular because of race/timing issues. Can an operator engineer a network such that the pseudo-wire or communications never or "rarely" fail from the perspective of routers/bridges? What is the cost and effectiveness (backup and rerouting pseudo-wire may not be sufficient as there can be many other reasons why communication is lost) in this case? I hope the L2VPN WG would consider these service issues as carefully as L2VPN discovery protocols because even the best L2VPN discovery protocols cannot help if the L2VPN service itself does not work well with routers and bridges. Thanks Cheng-Yin Tony Li wrote: > > Folks, > > In particular, if there is a disconnect on a broadcast medium > between two routers and neither is the DR, then the two routers > will present a black hole between them. This problem has been > seen before in real life and is Not Pretty. > > For this reason alone, I would encourage you to model any L2 > solution as a number of point-to-point links. > > Regards, > Tony Naiming Shen wrote: > > i don't think l2vpn wg needs to do much. when use link-state igp > in those places, ALWAYS assume it's unreliable. just use p2p. period. > > > | -----Original Message----- > | From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > | Sent: Tuesday, June 10, 2003 1:43 PM > | To: Tony Li > | Cc: Jeff Learman; Mailing List; isis-wg@ietf.org; Acee > | Lindem; l2vpn@ietf.org > | Subject: Re: [Isis-wg] Re: Inconsistent view of routers over a LAN > | > | > | Jeff, Tony, Acee, > | Thanks for your clarification. > | L2VPN WG is defining emulated LAN (and broadcast network > | for IP traffic) > | service over IP/MPLS network and some of the mechanims > | being defined can > | result in loss of communication among a subset of routers on the > | emulated LAN (even if all the nodes in the underlying > | IP/MPLS transport > | network are reachable). > | Some of the discussions have been how tolerable are > | routing protocols to > | this type of problem, if it is worth fixing some L2VPN WG > | mechanisms to > | prevent this problem, how feasible are these L2VPN > | solutions, are these > | not well-known problems ... > | > | I hope the L2VPN WG would consider these issues and > | requirements in the > | L2VPN solutions. > | Perhaps a more detailed understanding of how things > | work/don't work may > | help L2VPN WG develop/appreciate solutios that will work well with > | routers for e.g, in case of (i) below, what would an > | emulated LAN user > | observe in the routed network (is this predictable/unpredictable?) > | > | Thanks > | Cheng-Yin > | p.s I have cced l2vpn, but pls feel free to respond only > | to the relevant > | WG as is appropriate. > | > | Tony Li wrote: > | > > | > We should also point out that in case i) things are > | truly broken and > | > in case ii) the DR will not form an adjacency with A and > | the protocols > | > will be able to tell that things are broken. > | > > | > Tony > | > > | > | -----Original Message----- > | > | From: Jeff Learman [mailto:jlearman@cisco.com] > | > | Sent: Tuesday, June 10, 2003 9:29 AM > | > | To: Cheng-Yin.Lee@alcatel.com > | > | Cc: Mailing List; isis-wg@ietf.org > | > | Subject: Re: [Isis-wg] Re: Inconsistent view of > | routers over a LAN > | > | > | > | > | > | > | > | This violates the transitivity requirement stated > | in ISO 10589. > | > | You can't run ISIS on a subnetwork where this happens. > | > | At least, that's the theory ;) > | > | > | > | At 11:52 AM 6/10/2003, Cheng-Yin Lee wrote: > | > | >Hello, > | > | >Just got some private responses, perhaps I should clarify. > | > | >This is in context of an emulated LAN, and I am not > | > | looking for a fix in > | > | >routing protocols. > | > | > > | > | >Thanks > | > | >Cheng-Yin > | > | > > | > | >Cheng-Yin Lee wrote: > | > | >> > | > | >> Hello, > | > | >> What happens if for some reason Router A can't reach > | > | Router B, but > | > | >> Router C can reach A & B (and vice-versa), when > | Router A,B,C are > | > | >> connected over a broadcast network or LAN. > | > | >> > | > | >> E.g. in the case for (OSPF and IS-IS) where: > | > | >> i) C is the DR > | > | >> ii) B is the DR > | > | >> > | > | >> Thanks > | > | >> Cheng-Yin > | > | > | > Hi Cheng-Yin, > | > > | > What I've recommended in the past for these situations > | is to force > | > the routing protocol to view the underlying network as a P2MP > | > (Point-to-Multi-Point) network. Many vendors support this. For > | > example, in our implementation you'd simply configure: > | > > | > router ospf 1 > | > area 0 > | > interface backbone > | > network-type point-to-multipoint > | > o > | > o > | > < the rest of the OSPF config> > | > o > | > > | > Good Luck, > | > Acee > | > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 12 04:12:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00245 for ; Thu, 12 Jun 2003 04:12:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C89Jm29242; Thu, 12 Jun 2003 04:09:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C889m29181 for ; Thu, 12 Jun 2003 04:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29792 for ; Thu, 12 Jun 2003 04:08:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QN5t-0007ce-00 for isis-wg@ietf.org; Thu, 12 Jun 2003 04:06:01 -0400 Received: from [64.219.248.6] (helo=mailhost.metro-optix.com) by ietf-mx with esmtp (Exim 4.12) id 19QN5t-0007cb-00 for isis-wg@ietf.org; Thu, 12 Jun 2003 04:06:01 -0400 Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 03:01:26 -0500 Message-ID: <99EC34181384D611BE56000347227B2C193378@MAILHOSTNB> From: Sumesh K P To: "'isis-wg@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] Use of passive interface Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 03:00:53 -0500 Hi All, What is the exact user of setting an interface to passive. Should such an interface be present in the LSP data base though it does not send/receive any ISIS packets. Sumesh. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 12 10:15:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12948 for ; Thu, 12 Jun 2003 10:15:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEBhm25229; Thu, 12 Jun 2003 10:11:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEAqm25141 for ; Thu, 12 Jun 2003 10:10:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11933 for ; Thu, 12 Jun 2003 10:10:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSks-0002jo-00 for isis-wg@ietf.org; Thu, 12 Jun 2003 10:08:42 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19QSkr-0002jK-00 for isis-wg@ietf.org; Thu, 12 Jun 2003 10:08:41 -0400 Message-ID: From: Jeff Parker To: "'Sumesh K P'" , "'isis-wg@ietf.org'" Subject: RE: [Isis-wg] Use of passive interface MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 10:09:59 -0400 > What is the exact user of setting an interface to passive. > Should such an interface be present in the LSP data base > though it does not send/receive any ISIS packets. > > Sumesh. Sumesh - This allows you to advertise a direct route without having a peer on that interface. In English, if I have an interface to the 123.45/16 net, I may want to be able to advertise connectivity to that net, even if there is no IS-IS peer on that circuit, and thus no need to send hellos on that circuit. By marking the interface passive, we will include 123.45/16 as an IP reachability entry so that others know they can use me to get there. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 17 11:58:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24071 for ; Tue, 17 Jun 2003 11:58:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFL2a05095; Tue, 17 Jun 2003 11:21:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFKsm05084 for ; Tue, 17 Jun 2003 11:20:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22226 for ; Tue, 17 Jun 2003 11:20:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIEH-0000gQ-00 for Isis-wg@ietf.org; Tue, 17 Jun 2003 11:18:37 -0400 Received: from apollo.adtech-inc.com ([63.165.80.17]) by ietf-mx with esmtp (Exim 4.12) id 19SIEG-0000g7-00 for Isis-wg@ietf.org; Tue, 17 Jun 2003 11:18:36 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 05:20:17 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA213DB97@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'Isis-wg@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] IPv6 Address Summarization in L2LSP? Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 05:20:12 -1000 Hi WG, When ISIS is operating in the IPv6 Only environment, should I expect that the same mechanism of Address Summarization via manual configuration of L2 summary address as depicted in RFC 1195 section 3.2 be used? Thanks, CMC _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jun 17 16:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10277 for ; Tue, 17 Jun 2003 16:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SN4f-0008Qh-0O; Tue, 17 Jun 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMVo-0006S2-5d for isis-wg@optimus.ietf.org; Tue, 17 Jun 2003 15:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07968 for ; Tue, 17 Jun 2003 15:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMTZ-0004HI-00 for Isis-wg@ietf.org; Tue, 17 Jun 2003 15:50:41 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19SMTY-0004HE-00 for Isis-wg@ietf.org; Tue, 17 Jun 2003 15:50:40 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 7876323C34; Tue, 17 Jun 2003 12:51:45 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h5HJqMYB024755; Tue, 17 Jun 2003 12:52:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] IPv6 Address Summarization in L2LSP? Message-ID: Thread-Topic: [Isis-wg] IPv6 Address Summarization in L2LSP? Thread-Index: AcM07blQ2JdIgLVXTRefug1LoZI4kQAG/yYg From: "Tony Li" To: "Chan, Chung Ming" , Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 12:52:22 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10277 | When ISIS is operating in the IPv6 Only environment, | should I expect | that | the same mechanism of Address Summarization via manual | configuration | of | L2 summary address as depicted in RFC 1195 section 3.2 be used? I would certainly expect that. Summarization is absolutely necessary for scalability, and without manual configuration of the summarization, you would have to infer it dynamically. This would imply that the routers are capable of understanding the addressing plan for the network without manual input. They could also pick stocks. ;-) Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 05:42:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06274 for ; Thu, 19 Jun 2003 05:42:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Svg9-0004kx-DO; Thu, 19 Jun 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvOq-0003so-S2 for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 05:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05772 for ; Thu, 19 Jun 2003 05:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SvMY-00012w-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 05:05:46 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19SvMY-00012s-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 05:05:46 -0400 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Jun 2003 10:07:21 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8019753AD@baker.datcon.co.uk> From: Jon Berger To: "'isis-wg@ietf.org'" Cc: Alex Codd Subject: RE: [Isis-wg] Last Call: IS-IS Extensions in Support of Generaliz ed MPLS to Informational RFC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:07:22 +0100 I would like to suggest the following clarifications/corrections to this draft before next week's deadline. 1. For the Link Local/Remote ID sub-TLV: In section 3.1 the draft specifies that this sub-TLV 'MUST NOT occur more than once within the extended IS reachability TLV'. The limitation should actually be that the sub-TLV appear at most once per neighbor data structure. Likewise, where multiple instances of the sub-TLV are present, the draft dictates that if the 'sub-TLV occurs more than once within the extended IS reachability TLV, the receiver SHOULD ignore all these sub-TLVs'. As well as being incorrect for the reason stated above, I believe that this text is slightly unclear as to whether the receiver should discard all of the sub-TLVs, or just the superfluous ones (where my preference is the latter, which allows the receiver to be generous, and is preferable to ignoring all instances of the sub-TLV). My suggested replacement text for this section would be: 'The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than once per IS neighbor data structure within the extended IS reachability TLV. If the Link Local/Remote Identifiers sub-TLV occurs more than once within an IS neighbor data structure in an extended IS reachability TLV, the receiver SHOULD ignore all bar the first of these sub-TLVs'. Note that this also corrects the misspelling of 'Identifiers'. 2. For the Link Protection Type sub-TLV: Section 3.2 is erroneous in the same way as section 3.1 - I suggest altering the text to: 'The Link Protection Type sub-TLV MUST NOT occur more than once per IS neighbor data structure within the extended IS reachability TLV. If the Link Protection Type sub-TLV occurs more than once within an IS neighbor data structure in an extended IS reachability TLV, the receiver SHOULD ignore all bar the first of these sub-TLVs'. 3. For SRLG TLVs I believe that the description of the flag byte should include a comment specifically stating that the least significant bit determines whether Link IDs or IPv4 addresses will be used in the TLV (bit set to 1 - IP addresses, bit set to 0 - Link IDs). I propose adding the sentence: 'For a numbered interface, IPv4 addresses SHALL be used to describe the link, whereas for an unnumbered interface Link IDs SHALL be used.' 4. For SRLG TLVs I think that it would be advisable to have the following comment (as we do in the Link ID sub-TLV description): 'If the Link Remote Identifier is unknown, it is set to 0.' 5. In section 3.1 (the description of Link Local/Remote ID sub-TLVs), the sentence ending '...followed by four octets of Link Remote Idenfier' has a spelling mistake - should be IdenTIfier. Regards, Jon Jon Berger Data Connection Ltd Email: jrb@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 13:40:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03946 for ; Thu, 19 Jun 2003 13:40:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3OD-0000Wa-Mr; Thu, 19 Jun 2003 13:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3O5-0000W2-4j for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 13:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03885 for ; Thu, 19 Jun 2003 13:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Lm-00005C-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:37:30 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19T3Ll-00004q-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:37:29 -0400 Message-ID: From: Jeff Parker To: "'isis-wg@ietf.org'" Cc: "'mshand@cisco.com'" , "'ginsberg@cisco.com'" Subject: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 13:39:17 -0400 Mike, Les - Reviewing the restart draft, I see the following paragraph on page 5. 4.3.1 Adjacency reacquisition during restart .... When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses when they should be sent, but I don't see signs of an acceptance criteria for complete sets in 10589. Since CSNPs are not acknowledged and do not need to be sent in order, how much care is needed here? I can imagine an implementation that keeps track of the ranges seen, and keeps sending IIH with the RR bit sent, but I don't see a requirement on the "Helper" to retransmit the CSNPs. If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we are done, or must we hold on until we have an interlocking set? If we must hold on, should we require the Helper to resend the CSNPs? - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 13:52:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04624 for ; Thu, 19 Jun 2003 13:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Zo-0001bS-UA; Thu, 19 Jun 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Z2-0001VN-GC for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 13:51:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04543 for ; Thu, 19 Jun 2003 13:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Wj-0000Fo-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:48:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19T3Wi-0000FF-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:48:48 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2003 10:52:29 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5JHobUe011139; Thu, 19 Jun 2003 10:50:38 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-147.cisco.com [128.107.163.147]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHH42055; Thu, 19 Jun 2003 10:45:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619104452.019263b8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: "'isis-wg@ietf.org'" , "'mshand@cisco.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:50:36 -0700 At 01:39 PM 6/19/2003 -0400, Jeff Parker wrote: >Mike, Les - > >Reviewing the restart draft, I see the following paragraph on page 5. > >4.3.1 Adjacency reacquisition during restart > > .... > > When BOTH a complete set of CSNP(s) (for each active level, in the > case of a pt-pt circuit) and an acknowledgement have been received > over the interface, the timer T1 is cancelled. > >Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses >when they should be sent, but I don't see signs of an acceptance criteria >for complete sets in 10589. Since CSNPs are not acknowledged and do not >need to be sent in order, how much care is needed here? I can imagine an >implementation that keeps track of the ranges seen, and keeps sending IIH >with the RR bit sent, but I don't see a requirement on the "Helper" to >retransmit the CSNPs. According to Section 4.2.1c of the draft, the Helper is required to initiate transmission of a complete set of CSNPs every time it sees an IIH w RR set (assuming it is Pt-Pt or the appropriate system on the LAN). >If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we >are done, or must we hold on until we have an interlocking set? If we must >hold on, should we require the Helper to resend the CSNPs? You must track the receipt of a complete set of CSNPs. If you do not, then you cannot be assured of database synchronization. 10589 never made the transmission of CSNPs reliable. One of the goals of the draft is to make the transmission reliable so that database synchronization can be reached quickly and deterministically. Les >- jeff parker >- axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 14:01:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05418 for ; Thu, 19 Jun 2003 14:01:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3iX-0002Ap-Mc; Thu, 19 Jun 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3iS-0002AI-Fr for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 14:00:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05312 for ; Thu, 19 Jun 2003 14:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3g9-0000Rh-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:58:33 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19T3g8-0000RC-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 13:58:32 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: "'isis-wg@ietf.org'" , "'mshand@cisco.com'" Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 14:00:17 -0400 > According to Section 4.2.1c of the draft, the Helper is required to > initiate transmission of a complete set of CSNPs every time > it sees an IIH > w RR set (assuming it is Pt-Pt or the appropriate system on the LAN). Les - Thanks - that's what I missed. Interesting Datastructure problem, though I suppose nothing too fancy is required here. We could simply keep track of the lowest missing LSPID, as they whole list is comming around again. So the pacing dictated by 10589 is strong enough that we don't worry about determanistic PDU loss? (The helper is so much faster that the helpee always drops the 6th packet...) - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 19:14:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24877 for ; Thu, 19 Jun 2003 19:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8bQ-00010J-P6; Thu, 19 Jun 2003 19:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8aX-0000zx-5n for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 19:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24836 for ; Thu, 19 Jun 2003 19:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T8YE-0004Y3-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 19:10:42 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19T8YD-0004Xz-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 19:10:41 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h5JNBub01955; Fri, 20 Jun 2003 01:11:56 +0200 From: Hannes Gredler To: Les Ginsberg Cc: Jeff Parker , "'isis-wg@ietf.org'" , "'mshand@cisco.com'" Subject: Re: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Message-ID: <20030619231156.GA1919@juniper.net> References: <4.3.2.7.2.20030619104452.019263b8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030619104452.019263b8@mira-sjc5-3.cisco.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 01:11:56 +0200 On Thu, Jun 19, 2003 at 10:50:36AM -0700, Les Ginsberg wrote: | At 01:39 PM 6/19/2003 -0400, Jeff Parker wrote: | >Mike, Les - | > | >Reviewing the restart draft, I see the following paragraph on page 5. | > | >4.3.1 Adjacency reacquisition during restart | > | > .... | > | > When BOTH a complete set of CSNP(s) (for each active level, in the | > case of a pt-pt circuit) and an acknowledgement have been received | > over the interface, the timer T1 is cancelled. | > | >Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses | >when they should be sent, but I don't see signs of an acceptance criteria | >for complete sets in 10589. Since CSNPs are not acknowledged and do not | >need to be sent in order, how much care is needed here? I can imagine an | >implementation that keeps track of the ranges seen, and keeps sending IIH | >with the RR bit sent, but I don't see a requirement on the "Helper" to | >retransmit the CSNPs. | | According to Section 4.2.1c of the draft, the Helper is required to | initiate transmission of a complete set of CSNPs every time it sees an IIH | w RR set (assuming it is Pt-Pt or the appropriate system on the LAN). | | >If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we | >are done, or must we hold on until we have an interlocking set? If we must | >hold on, should we require the Helper to resend the CSNPs? | | You must track the receipt of a complete set of CSNPs. If you do not, then | you cannot be assured of database synchronization. | 10589 never made the transmission of CSNPs reliable. One of the goals of | the draft is to make the transmission reliable so that database | synchronization can be reached quickly and deterministically. what would be the "right" mechanism to track down a missing CSNP ? i.e. if i send the following CSNPs e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 assume now #2 gets lost; - is there a way for the receiver to track that #2 is missing ? IMHO not; one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is the start LSP-id of the next CSNP; e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00 CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00 comments ? /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jun 19 22:35:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00310 for ; Thu, 19 Jun 2003 22:35:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBjy-0004jR-Ay; Thu, 19 Jun 2003 22:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBjN-0004di-4G for isis-wg@optimus.ietf.org; Thu, 19 Jun 2003 22:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00271 for ; Thu, 19 Jun 2003 22:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBh2-0005sl-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 22:32:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TBh2-0005sX-00 for isis-wg@ietf.org; Thu, 19 Jun 2003 22:32:00 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2003 19:35:42 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5K2XnRM015344; Thu, 19 Jun 2003 19:33:50 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-147.cisco.com [128.107.163.147]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHH95693; Thu, 19 Jun 2003 19:29:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619192006.019641b8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hannes Gredler From: Les Ginsberg Subject: Re: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: Jeff Parker , "'isis-wg@ietf.org'" , "'mshand@cisco.com'" In-Reply-To: <20030619231156.GA1919@juniper.net> References: <4.3.2.7.2.20030619104452.019263b8@mira-sjc5-3.cisco.com> <4.3.2.7.2.20030619104452.019263b8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 19:33:48 -0700 At 01:11 AM 6/20/2003 +0200, Hannes Gredler wrote: >On Thu, Jun 19, 2003 at 10:50:36AM -0700, Les Ginsberg wrote: >| At 01:39 PM 6/19/2003 -0400, Jeff Parker wrote: >| >Mike, Les - >| > >| >Reviewing the restart draft, I see the following paragraph on page 5. >| > >| >4.3.1 Adjacency reacquisition during restart >| > >| > .... >| > >| > When BOTH a complete set of CSNP(s) (for each active level, in the >| > case of a pt-pt circuit) and an acknowledgement have been received >| > over the interface, the timer T1 is cancelled. >| > >| >Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses >| >when they should be sent, but I don't see signs of an acceptance criteria >| >for complete sets in 10589. Since CSNPs are not acknowledged and do not >| >need to be sent in order, how much care is needed here? I can imagine an >| >implementation that keeps track of the ranges seen, and keeps sending IIH >| >with the RR bit sent, but I don't see a requirement on the "Helper" to >| >retransmit the CSNPs. >| >| According to Section 4.2.1c of the draft, the Helper is required to >| initiate transmission of a complete set of CSNPs every time it sees an IIH >| w RR set (assuming it is Pt-Pt or the appropriate system on the LAN). >| >| >If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we >| >are done, or must we hold on until we have an interlocking set? If we must >| >hold on, should we require the Helper to resend the CSNPs? >| >| You must track the receipt of a complete set of CSNPs. If you do not, then >| you cannot be assured of database synchronization. >| 10589 never made the transmission of CSNPs reliable. One of the goals of >| the draft is to make the transmission reliable so that database >| synchronization can be reached quickly and deterministically. > >what would be the "right" mechanism to track down a missing CSNP ? > >i.e. if i send the following CSNPs > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 > >assume now #2 gets lost; - is there a way for the receiver to track that >#2 is missing ? IMHO not; The receiver knows that some information is missing. How many CSNPs might be required to fill in the missing information is unknown. It depends on the distribution of system IDs and the number of LSPs generated by each of the missing systems. >one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is >the start LSP-id of the next CSNP; > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00 > CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00 I would expect that most implementations send the CSNPs in this order - though such behavior is not required. However, if you are suggesting that as part of the restart draft we should specify additional requirements on CSNP exchange, then I am against that. Les >comments ? > >/hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 10:47:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09154 for ; Fri, 20 Jun 2003 10:47:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNAL-0001zt-04; Fri, 20 Jun 2003 10:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN9X-0001qu-0A for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 10:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09025 for ; Fri, 20 Jun 2003 10:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN9U-0004St-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 10:46:08 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19TN9T-0004SS-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 10:46:08 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Hannes Gredler Cc: "'isis-wg@ietf.org'" Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 10:45:20 -0400 To return to the example provided. Let's assume that all three of hannes' CSNPs arrive. Can we conclude that we have a full set? I don't see any numbering scheme, and I don't see any interlocking scheme that would tell us that there is nothing between 1111.1111.1111.00-01 and 2222.2222.2221.FF-FF (and likewise the gap between 2 and 3.) How do I know that the second CSNP is the second, and not the fifth? One way to make this reliable would be to add an optional "csnp sequence number" tlv. Thus it we have the numbers from 1 to k, and k has an end LSPID of all 1s, then we have a complete set. - jeff parker > >what would be the "right" mechanism to track down a missing CSNP ? > > > >i.e. if i send the following CSNPs > > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 Should that read as below? CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.ff-ff > >/hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 11:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11851 for ; Fri, 20 Jun 2003 11:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNeK-0004fy-Ss; Fri, 20 Jun 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNeB-0004fl-88 for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 11:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11820 for ; Fri, 20 Jun 2003 11:17:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNeA-0005Ob-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:17:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19TNe9-0005OM-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:17:50 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2003 17:17:29 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5KFFGTr007646; Fri, 20 Jun 2003 17:15:16 +0200 (MET DST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4299.cisco.com [10.61.80.202]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA29897; Fri, 20 Jun 2003 16:17:16 +0100 (BST) Message-Id: <4.3.2.7.2.20030620160853.0804a378@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: mike shand Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: "'Les Ginsberg'" , Hannes Gredler , "'isis-wg@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 16:17:15 +0100 Jeff, I don't understand the issue. 10589 is quite clear that A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). So while you still have gaps in the range, you have not received a complete set. I don't see why you need a sequence number. Mike At 10:45 20/06/2003 -0400, Jeff Parker wrote: >To return to the example provided. Let's assume that all three of hannes' >CSNPs arrive. Can we conclude that we have a full set? > >I don't see any numbering scheme, and I don't see any interlocking scheme >that would tell us that there is nothing between 1111.1111.1111.00-01 and >2222.2222.2221.FF-FF (and likewise the gap between 2 and 3.) How do I know >that the second CSNP is the second, and not the fifth? > >One way to make this reliable would be to add an optional "csnp sequence >number" tlv. Thus it we have the numbers from 1 to k, and k has an end >LSPID of all 1s, then we have a complete set. > >- jeff parker > > > >what would be the "right" mechanism to track down a missing CSNP ? > > > > > >i.e. if i send the following CSNPs > > > > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 > >Should that read as below? > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.ff-ff > > > >/hannes > > > > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 11:21:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11972 for ; Fri, 20 Jun 2003 11:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNhF-0004n3-6T; Fri, 20 Jun 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNgY-0004le-ML for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 11:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11915 for ; Fri, 20 Jun 2003 11:20:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNgX-0005Pp-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:20:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TNgX-0005Pm-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:20:17 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2003 08:17:58 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KFJdIX024364; Fri, 20 Jun 2003 08:19:39 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-763.cisco.com [10.21.66.251]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHI25525; Fri, 20 Jun 2003 08:14:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620075942.01a7dc80@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: Hannes Gredler , "'isis-wg@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 08:19:20 -0700 At 10:45 AM 6/20/2003 -0400, Jeff Parker wrote: >To return to the example provided. Let's assume that all three of hannes' >CSNPs arrive. Can we conclude that we have a full set? > >I don't see any numbering scheme, and I don't see any interlocking scheme >that would tell us that there is nothing between 1111.1111.1111.00-01 and >2222.2222.2221.FF-FF (and likewise the gap between 2 and 3.) How do I know >that the second CSNP is the second, and not the fifth? Jeff - An implementation that interprets 10589 7.3.15.3 as: If multiple CSNPs are required to make up a complete set AND there are no LSPs that fall into the range between (for example) 1111.1111.1111.00-00 - 1111.1111.1111.ff-ff THEN I can send CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 etc. (i.e. never cover the "1111" range in any of the start/end ranges in any of the CSNPs) and say that I have sent a "complete set" , then that implementation is non-conforming - or at least "brain-damaged". It costs an implementation nothing to make sure that the range is covered completely i.e. no additional PDUs are required, you simply have to change the start ID on the second CSNP to be: CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 (or extend the end range of CSNP #1). >One way to make this reliable would be to add an optional "csnp sequence >number" tlv. Thus it we have the numbers from 1 to k, and k has an end >LSPID of all 1s, then we have a complete set. Given the above, I do not see that this adds any value. >- jeff parker > > > >what would be the "right" mechanism to track down a missing CSNP ? > > > > > >i.e. if i send the following CSNPs > > > > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 > >Should that read as below? > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.ff-ff > > > >/hannes > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 11:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13012 for ; Fri, 20 Jun 2003 11:34:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNto-00068s-MS; Fri, 20 Jun 2003 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNsr-000603-Bi for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 11:33:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12941 for ; Fri, 20 Jun 2003 11:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNsq-0005fP-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:33:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19TNsp-0005eK-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:32:59 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2003 17:32:40 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5KFUQg6010695; Fri, 20 Jun 2003 17:30:26 +0200 (MET DST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4299.cisco.com [10.61.80.202]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA00890; Fri, 20 Jun 2003 16:32:24 +0100 (BST) Message-Id: <4.3.2.7.2.20030620162938.08227130@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: Jeff Parker , Hannes Gredler , "'isis-wg@ietf.org'" In-Reply-To: <4.3.2.7.2.20030620075942.01a7dc80@mira-sjc5-3.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 16:32:22 +0100 At 08:19 20/06/2003 -0700, Les Ginsberg wrote: >At 10:45 AM 6/20/2003 -0400, Jeff Parker wrote: >>To return to the example provided. Let's assume that all three of hannes' >>CSNPs arrive. Can we conclude that we have a full set? >> >>I don't see any numbering scheme, and I don't see any interlocking scheme >>that would tell us that there is nothing between 1111.1111.1111.00-01 and >>2222.2222.2221.FF-FF (and likewise the gap between 2 and 3.) How do I know >>that the second CSNP is the second, and not the fifth? > >Jeff - > >An implementation that interprets 10589 7.3.15.3 as: > >If multiple CSNPs are required to make up a complete set AND there are no >LSPs that fall into the range between (for example) 1111.1111.1111.00-00 - >1111.1111.1111.ff-ff THEN I can send > > >CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 >CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 >etc. > >(i.e. never cover the "1111" range in any of the start/end ranges in any >of the CSNPs) > >and say that I have sent a "complete set" , then that implementation is >non-conforming - or at least "brain-damaged". It is certainly seriously broken, since if a neighbor HAS an LSP within the range (however small) which was omitted, it will never be triggered to re-transmit it. Thats why 10589 says a "complete" range and defines what it is. There is no room for slapdashness here. Mike >It costs an implementation nothing to make sure that the range is covered >completely i.e. no additional PDUs are required, you simply have to change >the start ID on the second CSNP to be: > >CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 > >(or extend the end range of CSNP #1). > > >>One way to make this reliable would be to add an optional "csnp sequence >>number" tlv. Thus it we have the numbers from 1 to k, and k has an end >>LSPID of all 1s, then we have a complete set. > >Given the above, I do not see that this adds any value. > > >>- jeff parker >> >> > >what would be the "right" mechanism to track down a missing CSNP ? >> > > >> > >i.e. if i send the following CSNPs >> > > >> > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 >> > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 >> > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 >> >>Should that read as below? >> CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.ff-ff >> >> > >/hannes > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 11:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13270 for ; Fri, 20 Jun 2003 11:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNvk-0006HQ-LV; Fri, 20 Jun 2003 11:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TNuu-0006Ef-Ji for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 11:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13099 for ; Fri, 20 Jun 2003 11:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TNut-0005hx-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:35:07 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19TNus-0005h6-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:35:07 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: Hannes Gredler , "'isis-wg@ietf.org'" Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 11:34:23 -0400 > It costs an implementation nothing to make sure that the > range is covered completely i.e. no additional PDUs are > required, you simply have to change the start ID on the > second CSNP to be: > > CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 > > (or extend the end range of CSNP #1). > > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 Les - Great. That was what I took to be "interlocking" that I thought you had ruled out in an earlier mail. Looking at 10589, section 9.10 9.10 Level 1 complete sequence ... - Start LSP ID - the LSP ID of first LSP in the range covered by this Complete Sequence Numbers PDU. - End LSP ID - the LSP ID of last LSP in the range covered by this Complete Sequence Numbers PDU. I read this yesterday to mean the LSP ID of real LSPs in the CSNP, rather than the LSP ID of a hypothetical LSP that could exist. Rereading it now, I agree that could be read as you suggest. I have looked at one implementation that does not seem to do the right thing here. Is this worth adding to the Interoperability draft? - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jun 20 11:48:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14115 for ; Fri, 20 Jun 2003 11:48:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TO7N-0007H3-Is; Fri, 20 Jun 2003 11:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TO6e-0007FX-3a for isis-wg@optimus.ietf.org; Fri, 20 Jun 2003 11:47:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14033 for ; Fri, 20 Jun 2003 11:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TO6c-0005uu-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:47:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19TO6c-0005ua-00 for isis-wg@ietf.org; Fri, 20 Jun 2003 11:47:14 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2003 08:49:30 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5KFkfRM017729; Fri, 20 Jun 2003 08:46:42 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-763.cisco.com [10.21.66.251]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHI27571; Fri, 20 Jun 2003 08:41:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620084219.01a6dd48@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: Hannes Gredler , "'isis-wg@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3805371==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 08:46:40 -0700 --=====================_3805371==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Here is what 10589 says in 7.3.15.3 A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). Where more than one CSNP is transmitted on a broadcast circuit, they shall be separated by an interval of at least minimumBroadcast-LSPTransmissionInterval. Note in particular the phrase: (i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set) I don't think there is ANY ambiguity here nor any need for further clarification. Les At 11:34 AM 6/20/2003 -0400, Jeff Parker wrote: > > > It costs an implementation nothing to make sure that the > > range is covered completely i.e. no additional PDUs are > > required, you simply have to change the start ID on the > > second CSNP to be: > > > > CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 > > > > (or extend the end range of CSNP #1). > > > > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > > > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > > > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 > >Les - > Great. That was what I took to be "interlocking" that I thought you >had ruled out in an earlier mail. > >Looking at 10589, section 9.10 > > 9.10 Level 1 complete sequence > ... > - Start LSP ID - the LSP ID of first LSP in the range covered by this >Complete Sequence Numbers PDU. > - End LSP ID - the LSP ID of last LSP in the range covered by this >Complete Sequence Numbers PDU. > >I read this yesterday to mean the LSP ID of real LSPs in the CSNP, rather >than the LSP ID of a hypothetical LSP that could exist. Rereading it now, I >agree that could be read as you suggest. > >I have looked at one implementation that does not seem to do the right thing >here. > >Is this worth adding to the Interoperability draft? > >- jeff parker --=====================_3805371==_.ALT Content-Type: text/html; charset="us-ascii" Here is what 10589 says in 7.3.15.3

A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). Where more than one CSNP is transmitted on a broadcast circuit, they shall be separated by an interval of at least minimumBroadcast-LSPTransmissionInterval.

Note in particular the phrase:

(i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set)

I don't think there is ANY ambiguity here nor any need for further clarification.

   Les


At 11:34 AM 6/20/2003 -0400, Jeff Parker wrote:
 
> It costs an implementation nothing to make sure that the
> range is covered completely i.e. no additional PDUs are
> required, you simply have to change the start ID on the
> second CSNP to be:
>
> CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00
>
> (or extend the end range of CSNP #1).
 
> > > >e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00
> > > >      CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00
> > > >      CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00

Les -
        Great.  That was what I took to be "interlocking" that I thought you
had ruled out in an earlier mail. 

Looking at 10589, section 9.10
 
   9.10 Level 1 complete sequence
   ...
   - Start LSP ID - the LSP ID of first LSP in the range covered by this
Complete Sequence Numbers PDU.
   - End LSP ID - the LSP ID of last LSP in the range covered by this
Complete Sequence Numbers PDU.

I read this yesterday to mean the LSP ID of real LSPs in the CSNP, rather
than the LSP ID of a hypothetical LSP that could exist.  Rereading it now, I
agree that could be read as you suggest.

I have looked at one implementation that does not seem to do the right thing
here.

Is this worth adding to the Interoperability draft?

- jeff parker
--=====================_3805371==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jun 21 14:29:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12131 for ; Sat, 21 Jun 2003 14:29:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tn6j-0005PZ-HM; Sat, 21 Jun 2003 14:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tn6f-0005PC-KP for isis-wg@optimus.ietf.org; Sat, 21 Jun 2003 14:28:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12099 for ; Sat, 21 Jun 2003 14:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tn6d-0000VE-00 for isis-wg@ietf.org; Sat, 21 Jun 2003 14:28:55 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19Tn6c-0000V5-00 for isis-wg@ietf.org; Sat, 21 Jun 2003 14:28:54 -0400 Message-ID: From: Jeff Parker To: "'Hannes Gredler'" Cc: "'isis-wg@ietf.org'" Subject: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 21 Jun 2003 14:28:14 -0400 Since I opened this can of worms, I should try to get the worms back in the can. Thanks to Mike and Les for sorting this out for me. > what would be the "right" mechanism to track down a missing CSNP ? > i.e. if i send the following CSNPs > > e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 As you noted, this does not cover the range from 00....00 to FF.....FF. If there is a LAN client X that is not the DIS is holding LSP 1111.1111.1112.0000, X would not be forced to flood the missing LSP. > one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is > the start LSP-id of the next CSNP; > > e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00 > CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00 > > /hannes This meets the requirements from 7.3.15.3: A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e. there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). However, it is possible to meet this condition without repeating an LSP ID, so receivers cannot depend on seeing the overlaps to decide if the sequence is complete. One such abutting sequence increments the last LSPID in the previous CSNP fragment, as below. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 CSNP #3 3333.3333.3333.00-01 -> ffff.ffff.ffff.ff-ff - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jun 21 15:45:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14386 for ; Sat, 21 Jun 2003 15:45:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ToIH-0007PE-7H; Sat, 21 Jun 2003 15:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ToID-0007Ox-Cq for isis-wg@optimus.ietf.org; Sat, 21 Jun 2003 15:44:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14349 for ; Sat, 21 Jun 2003 15:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ToIB-0000mD-00 for isis-wg@ietf.org; Sat, 21 Jun 2003 15:44:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ToIB-0000m6-00 for isis-wg@ietf.org; Sat, 21 Jun 2003 15:44:55 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2003 21:44:36 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5LJgMtW016525; Sat, 21 Jun 2003 21:42:22 +0200 (MET DST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp140.cisco.com [10.61.64.140]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA03716; Sat, 21 Jun 2003 20:44:21 +0100 (BST) Message-Id: <4.3.2.7.2.20030621203922.00b7d590@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: mike shand Subject: Re: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt Cc: "'Hannes Gredler'" , "'isis-wg@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 21 Jun 2003 20:44:07 +0100 Thanks, Jeff. Just one comment on the concept of overlapping ranges. Although this perhaps meets the requirements in a strict sense, it is somewhat perverse and I would think it would be a bad idea, since the most obvious implementation for the receiver of a CSNP is to set SRMflags for any LSP which it holds which is within the bound of a received CSNP, but not otherwise mentioned (i.e. the sender doesn't have it). If a receiver happened to have an LSP which corresponded to the overlap, then it would get sent twice (assuming the CSNP "fragments" arrived sufficiently far apart for the LSP to have been transmitted. Obviously not a problem, but perhaps not a terribly good idea. I see no reason whatsoever to use overlapping CSNP ranges. Mike At 14:28 21/06/2003 -0400, Jeff Parker wrote: >Since I opened this can of worms, I should try to get the worms back in the >can. Thanks to Mike and Les for sorting this out for me. > > > what would be the "right" mechanism to track down a missing CSNP ? > > i.e. if i send the following CSNPs > > > > e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 > > CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 > >As you noted, this does not cover the range from 00....00 to FF.....FF. If >there is a LAN client X that is not the DIS is holding LSP >1111.1111.1112.0000, X would not be forced to flood the missing LSP. > > > one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is > > the start LSP-id of the next CSNP; > > > > e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 > > CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00 > > CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00 > > > > /hannes > >This meets the requirements from 7.3.15.3: > > A complete set of CSNPs is a set whose Start > LSPID and End LSPID ranges cover the complete > possible range of LSPIDs. (i.e. there is no > possible LSPID value which does not appear > within the range of one of the CSNPs in the set). > >However, it is possible to meet this condition without repeating an LSP ID, >so receivers cannot depend on seeing the overlaps to decide if the sequence >is complete. > >One such abutting sequence increments the last LSPID in the previous CSNP >fragment, as below. > >CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 >CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00 >CSNP #3 3333.3333.3333.00-01 -> ffff.ffff.ffff.ff-ff > >- jeff parker > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 22 08:48:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10591 for ; Sun, 22 Jun 2003 08:48:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U4GG-0008DN-Sy; Sun, 22 Jun 2003 08:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U4FT-0008D4-Hj for isis-wg@optimus.ietf.org; Sun, 22 Jun 2003 08:47:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10504 for ; Sun, 22 Jun 2003 08:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U4FD-0004C8-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 08:46:55 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19U4F2-0004Bw-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 08:46:44 -0400 Received: from net4u.ch (zux006-022-240.adsl.green.ch [81.6.22.240]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h5MClD74016704; Sun, 22 Jun 2003 14:47:14 +0200 Message-ID: <3EF5A3C5.4050507@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Parker CC: "'Hannes Gredler'" , "'isis-wg@ietf.org'" Subject: Re: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Jun 2003 14:40:37 +0200 Content-Transfer-Encoding: 7bit Jeff Parker wrote: >Since I opened this can of worms, I should try to get the worms back in the >can. Thanks to Mike and Les for sorting this out for me. > > > >>what would be the "right" mechanism to track down a missing CSNP ? >>i.e. if i send the following CSNPs >> >>e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 >> CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00 >> CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00 >> >> > >As you noted, this does not cover the range from 00....00 to FF.....FF. If >there is a LAN client X that is not the DIS is holding LSP >1111.1111.1112.0000, X would not be forced to flood the missing LSP. > > > >>one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is >>the start LSP-id of the next CSNP; >> >>e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00 >> CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00 >> CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00 >> >>/hannes >> >> > >This meets the requirements from 7.3.15.3: > > A complete set of CSNPs is a set whose Start > LSPID and End LSPID ranges cover the complete > possible range of LSPIDs. (i.e. there is no > possible LSPID value which does not appear > within the range of one of the CSNPs in the set). > >However, it is possible to meet this condition without repeating an LSP ID, >so receivers cannot depend on seeing the overlaps to decide if the sequence >is complete. > and of course there is no guarantee that (or rather requirement) that you receive the CSNPs in the same order they have been sent which could put you into hot water anyway if you start to rely on an overlap. thanks - tony > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 22 17:09:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18772 for ; Sun, 22 Jun 2003 17:09:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UC57-0003Vf-Ai; Sun, 22 Jun 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UC4S-0003VR-H2 for isis-wg@optimus.ietf.org; Sun, 22 Jun 2003 17:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18670; Sun, 22 Jun 2003 17:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UC3U-0005YC-00; Sun, 22 Jun 2003 17:07:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UC3J-0005Y5-00; Sun, 22 Jun 2003 17:07:09 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2003 14:04:58 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5ML69qd014067; Sun, 22 Jun 2003 14:06:09 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIJ85154; Sun, 22 Jun 2003 13:59:31 -0700 (PDT) Message-ID: <3EF61A3E.793B3046@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: isis-wg@ietf.org Content-Type: multipart/mixed; boundary="------------9F1149E4458680D2810E267F" Subject: [Isis-wg] draft-raszuk-isis-bgp-peer-discovery-00.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Jun 2003 23:06:06 +0200 This is a multi-part message in MIME format. --------------9F1149E4458680D2810E267F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------9F1149E4458680D2810E267F Content-Type: text/plain; charset=us-ascii; name="draft-raszuk-isis-bgp-peer-discovery-00.txt" Content-Disposition: inline; filename="draft-raszuk-isis-bgp-peer-discovery-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Robert Raszuk (Editor) Internet Draft Cisco Systems, Inc Category: Standards Track June 2003 Expires: December 2003 ISIS Extensions for BGP Peer Discovery draft-raszuk-isis-peer-discovery-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes an extension to IS-IS protocol [ISO10589] to support BGP peer auto discovery. We propose the addition of new information that an Intermediate System can flood in it's LSPDU. Such information is required for network based auto discovery of IBGP peers as described in [IBGP-AM]. Raszuk R. Expires Dec 2003 [Page 1] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Today all BGP peering configuration is manual and requires action on both sides of any given peering. In IBGP Auto Mesh draft [IBGP-AM] we propose the automation of this task for IBGP sessions. As a distribution of required information IS-IS [ISO10589] native flooding layer is being proposed for reuse. The information required to be flooded is static and can change only by operator's manual configuration action. It is envisioned that in the future when new and better approaches for flooding information are available and deployed BGP Auto Discovery TLV could also be migrated from ISIS to such a new transport. 3. The BGP Auto Discovery TLV BGP Auto Discovery TLV is an IS-IS TLV of type code 243 (to be confirmed). The format of BGP Auto Discovery TLV is indicated for reference in Figure 1 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | Length | FLOODING RESERVED |F|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FRAG | BGP RESERVED | 16 bit CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Autonomous System(s) or confederation sub-AS(s) sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4/IPv6 Peering Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI/SAFI for mesh topologies sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI/SAFI for reflection topologies sub-TLV | Raszuk R. Expires Dec 2003 [Page 2] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old BGP Identifier sub-TLV (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. BGP Auto Discovery TLV Type - Code 243 (to be confirmed) Length - Total length in octets Control Flags related to IGP operation: Symbol Capabilities F Flooding scope D Down Bit "F" {flooding} flooding scope of this TLV, when set domain wide flooding scope is required, when not set TLV should not be flooded into other areas or levels. Default not set indicating area/level wide flooding only. "D" {down} down bit set by IGP when leaked to other levels. BGP Auto Discovery TLV can be contained in any LSP fragment. It also can be repeated. BGP itself will take all necessary filtering/update actions on reception of this information from ISIS. The minimum TLV length can be 10 octets. When a size of the TLV reaches 255 octets BGP will fragment the TLV. A special "FRAG" 4 bit counter has been allocated in the BGP Control Information section for unlikely cases where BGP Auto Discovery TLV needs to be splitted across multiple TLVs for a given BGP speaker. Fragmentation should be fully transparent to ISIS component. The specific information and encoding of BGP sub-TLVs is discussed in [IBGP-AM]. Raszuk R. Expires Dec 2003 [Page 3] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 4. Operation It should be important to emphasize the fact that ISIS interaction with the new information is to remain minimal. BGP component will prepare the necessary information to be flooded as well as keep the received information in it's own data structure (cache). BGP component will also inform ISIS about required flooding scope for it's information by setting the F bit. It is assumed that all global LSP comparison will still take place. On the other hand it is not required that ISIS will try to parse and compare the TLV itself and based on the result initiate BGP notification or not. Added checksum field should make comparison done by BGP much less CPU intensive. Forced reflooding should only take place based on the manual configuration change of session related parameters. During normal network operation when BGP configuration related to peer maintenance is constant BGP Auto Discovery TLV should not cause any extra processing or flooding for ISIS. 5. Deployment Considerations The new proposed data to be flooded has an informational character. Routers which do not understand new information will not be able to participate in the IBGP auto mesh. Deployment of new code which supports new information can be incremental. Also enabling information distribution itself can also have an incremental character. It should be up to operator's decision to switch from informational use of BGP Auto Discovery TLV to operational IBGP auto mesh benefits. 6. IANA Considerations A new ISIS TLV type will need to be assigned by IANA. The TLV assignee will be responsible for allocation of any sub-TLVs for the IANA assigned TLV. Raszuk R. Expires Dec 2003 [Page 4] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 7. Security Considerations It is highly encouraged to use existing ISIS security mechanism when transporting BGP Auto Discovery TLV. While addition of new information does not present any additional risks, potential consequences of injection of not authorized BGP Auto Discovery TLVs into routing domain could by minimized by implementation of additional filtering before attempting to establish IBGP sessions. 8. Acknowledgments I would like to express special thanks to Stefano Previdi, Steven Luong & Abhay Roy for their comments. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [ISO10589] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO8473)" [Also republished as RFC 1142] [RFC2966] T. Li, T. Przygienda, H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", October 2000. 10. Informative References [IBGP-AM] Raszuk, R., "IBGP Auto Mesh", draft-raszuk-ibgp-auto- mesh-00.txt, June 2003 Raszuk R. Expires Dec 2003 [Page 5] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 11. Authors' Addresses Robert Raszuk Cisco Systems, Inc. Al. Jerozolimskie 146C 02-305 Warsaw, Poland Email: rraszuk@cisco.com 12. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Terms of Use Cisco has a pending patent which relates to the subject matter of this Internet Draft. If a standard relating to this subject matter is adopted by IETF and any claims of any issued Cisco patents are necessary for practicing this standard, any party will be able to obtain a license from Cisco to use any such patent claims under openly specified, reasonable, non-discriminatory terms to implement and fully comply with the standard. Raszuk R. Expires Dec 2003 [Page 6] Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 14. Full Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Raszuk R. Expires Dec 2003 [Page 7] --------------9F1149E4458680D2810E267F-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 22 18:00:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19418 for ; Sun, 22 Jun 2003 18:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCsT-0004Vs-Qe; Sun, 22 Jun 2003 18:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCrw-0004VD-Ck for isis-wg@optimus.ietf.org; Sun, 22 Jun 2003 17:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19382 for ; Sun, 22 Jun 2003 17:59:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UCre-0005hl-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 17:59:10 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19UCrM-0005hb-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 17:58:52 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h5MLvmV22046; Sun, 22 Jun 2003 23:57:48 +0200 From: Hannes Gredler To: Robert Raszuk Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raszuk-isis-bgp-peer-discovery-00.txt Message-ID: <20030622215748.GA22031@juniper.net> References: <3EF61A3E.793B3046@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF61A3E.793B3046@cisco.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Jun 2003 23:57:48 +0200 robert, pls could you post draft-raszuk-ibgp-auto-mesh-00.txt as well as i was not able to find it; /hannes On Sun, Jun 22, 2003 at 11:06:06PM +0200, Robert Raszuk wrote: | | | | | | | | Network Working Group Robert Raszuk (Editor) | Internet Draft Cisco Systems, Inc | Category: Standards Track June 2003 | Expires: December 2003 | | | ISIS Extensions for BGP Peer Discovery | draft-raszuk-isis-peer-discovery-00.txt | | | Status of this Memo | | This document is an Internet-Draft and is in full conformance with | all provisions of Section 10 of RFC2026. | | Internet Drafts are working documents of the Internet Engineering | Task Force (IETF), its Areas, and its Working Groups. Note that other | groups may also distribute working documents as Internet Drafts. | | Internet Drafts are draft documents valid for a maximum of six | months. Internet Drafts may be updated, replaced, or obsolete by | other documents at any time. It is not appropriate to use Internet | Drafts as reference material or to cite them other than as a "working | draft" or "work in progress". | | The list of current Internet-Drafts can be accessed at | http://www.ietf.org/ietf/1id-abstracts.txt | | The list of Internet-Draft Shadow Directories can be accessed at | http://www.ietf.org/shadow.html. | | | Abstract | | This document proposes an extension to IS-IS protocol [ISO10589] to | support BGP peer auto discovery. | | We propose the addition of new information that an Intermediate | System can flood in it's LSPDU. Such information is required for | network based auto discovery of IBGP peers as described in [IBGP-AM]. | | | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 1] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | 1. Specification of Requirements | | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | document are to be interpreted as described in [RFC2119]. | | | 2. Introduction | | Today all BGP peering configuration is manual and requires action on | both sides of any given peering. In IBGP Auto Mesh draft [IBGP-AM] we | propose the automation of this task for IBGP sessions. As a | distribution of required information IS-IS [ISO10589] native flooding | layer is being proposed for reuse. | | The information required to be flooded is static and can change only | by operator's manual configuration action. | | It is envisioned that in the future when new and better approaches | for flooding information are available and deployed BGP Auto | Discovery TLV could also be migrated from ISIS to such a new | transport. | | | 3. The BGP Auto Discovery TLV | | BGP Auto Discovery TLV is an IS-IS TLV of type code 243 (to be | confirmed). | | The format of BGP Auto Discovery TLV is indicated for reference in | Figure 1 below. | | 0 1 2 3 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TLV Type | Length | FLOODING RESERVED |F|D| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | BGP Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | FRAG | BGP RESERVED | 16 bit CHECKSUM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Autonomous System(s) or confederation sub-AS(s) sub-TLV | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv4/IPv6 Peering Address sub-TLV | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AFI/SAFI for mesh topologies sub-TLV | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AFI/SAFI for reflection topologies sub-TLV | | | | | Raszuk R. Expires Dec 2003 [Page 2] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Old BGP Identifier sub-TLV (opt) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Figure 1. BGP Auto Discovery TLV | | Type - Code 243 (to be confirmed) | Length - Total length in octets | | Control Flags related to IGP operation: | | Symbol Capabilities | | F Flooding scope | D Down Bit | | "F" {flooding} flooding scope of this TLV, when set domain wide | flooding scope is required, when not set TLV should not be | flooded into other areas or levels. Default not set | indicating area/level wide flooding only. | | "D" {down} down bit set by IGP when leaked to other levels. | | BGP Auto Discovery TLV can be contained in any LSP fragment. It also | can be repeated. BGP itself will take all necessary filtering/update | actions on reception of this information from ISIS. | | The minimum TLV length can be 10 octets. | | When a size of the TLV reaches 255 octets BGP will fragment the TLV. | A special "FRAG" 4 bit counter has been allocated in the BGP Control | Information section for unlikely cases where BGP Auto Discovery TLV | needs to be splitted across multiple TLVs for a given BGP speaker. | Fragmentation should be fully transparent to ISIS component. | | The specific information and encoding of BGP sub-TLVs is discussed in | [IBGP-AM]. | | | | | | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 3] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | 4. Operation | | It should be important to emphasize the fact that ISIS interaction | with the new information is to remain minimal. BGP component will | prepare the necessary information to be flooded as well as keep the | received information in it's own data structure (cache). BGP | component will also inform ISIS about required flooding scope for | it's information by setting the F bit. | | It is assumed that all global LSP comparison will still take place. | On the other hand it is not required that ISIS will try to parse and | compare the TLV itself and based on the result initiate BGP | notification or not. Added checksum field should make comparison done | by BGP much less CPU intensive. | | Forced reflooding should only take place based on the manual | configuration change of session related parameters. During normal | network operation when BGP configuration related to peer maintenance | is constant BGP Auto Discovery TLV should not cause any extra | processing or flooding for ISIS. | | | 5. Deployment Considerations | | The new proposed data to be flooded has an informational character. | Routers which do not understand new information will not be able to | participate in the IBGP auto mesh. | | Deployment of new code which supports new information can be | incremental. Also enabling information distribution itself can also | have an incremental character. | | It should be up to operator's decision to switch from informational | use of BGP Auto Discovery TLV to operational IBGP auto mesh benefits. | | | 6. IANA Considerations | | A new ISIS TLV type will need to be assigned by IANA. The TLV | assignee will be responsible for allocation of any sub-TLVs for the | IANA assigned TLV. | | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 4] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | 7. Security Considerations | | It is highly encouraged to use existing ISIS security mechanism when | transporting BGP Auto Discovery TLV. | | While addition of new information does not present any additional | risks, potential consequences of injection of not authorized BGP Auto | Discovery TLVs into routing domain could by minimized by | implementation of additional filtering before attempting to establish | IBGP sessions. | | | 8. Acknowledgments | | I would like to express special thanks to Stefano Previdi, Steven | Luong & Abhay Roy for their comments. | | | 9. Normative References | | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | Requirement Levels", RFC 2119, March 1997. | | [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an | IANA Considerations Section in RFCs", RFC 2434, October 1998. | | [ISO10589] "Intermediate System to Intermediate System Intra-Domain | Routing Exchange Protocol for use in Conjunction with the | Protocol for Providing the Connectionless-mode Network Service | (ISO8473)" [Also republished as RFC 1142] | | [RFC2966] T. Li, T. Przygienda, H. Smit, "Domain-wide Prefix | Distribution with Two-Level IS-IS", October 2000. | | | 10. Informative References | | [IBGP-AM] Raszuk, R., "IBGP Auto Mesh", draft-raszuk-ibgp-auto- | mesh-00.txt, June 2003 | | | | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 5] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | 11. Authors' Addresses | | Robert Raszuk | Cisco Systems, Inc. | Al. Jerozolimskie 146C | 02-305 Warsaw, Poland | Email: rraszuk@cisco.com | | | | 12. IPR Notices | | The IETF takes no position regarding the validity or scope of any | intellectual property or other rights that might be claimed to | pertain to the implementation or use of the technology described in | this document or the extent to which any license under such rights | might or might not be available; neither does it represent that it | has made any effort to identify any such rights. Information on the | IETF's procedures with respect to rights in standards-track and | standards-related documentation can be found in BCP-11. Copies of | claims of rights made available for publication and any assurances of | licenses to be made available, or the result of an attempt made to | obtain a general license or permission for the use of such | proprietary rights by implementors or users of this specification can | be obtained from the IETF Secretariat. | | The IETF invites any interested party to bring to its attention any | copyrights, patents or patent applications, or other proprietary | rights which may cover technology that may be required to practice | this standard. Please address the information to the IETF Executive | Director. | | | 13. Terms of Use | | Cisco has a pending patent which relates to the subject matter of | this Internet Draft. If a standard relating to this subject matter | is adopted by IETF and any claims of any issued Cisco patents are | necessary for practicing this standard, any party will be able to | obtain a license from Cisco to use any such patent claims under | openly specified, reasonable, non-discriminatory terms to implement | and fully comply with the standard. | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 6] | | | | | | Internet Draft ISIS Ext for IBGP Auto Mesh June 2003 | | | 14. Full Copyright Notice | | Copyright (C) The Internet Society (2002). All Rights Reserved. | | This document and translations of it may be copied and furnished to | others, and derivative works that comment on or otherwise explain it | or assist in its implementation may be prepared, copied, published | and distributed, in whole or in part, without restriction of any | kind, provided that the above copyright notice and this paragraph are | included on all such copies and derivative works. However, this | document itself may not be modified in any way, such as by removing | the copyright notice or references to the Internet Society or other | Internet organizations, except as needed for the purpose of | developing Internet standards in which case the procedures for | copyrights defined in the Internet Standards process must be | followed, or as required to translate it into languages other than | English. | | The limited permissions granted above are perpetual and will not be | revoked by the Internet Society or its successors or assigns. | | This document and the information contained herein is provided on an | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | | | | | | | | | | | | | | | | | | | | | | | | | Raszuk R. Expires Dec 2003 [Page 7] | | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jun 22 18:06:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19846 for ; Sun, 22 Jun 2003 18:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCyG-0004ed-M9; Sun, 22 Jun 2003 18:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCxK-0004eH-P3 for isis-wg@optimus.ietf.org; Sun, 22 Jun 2003 18:05:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19672 for ; Sun, 22 Jun 2003 18:04:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UCxI-0005jU-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 18:05:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UCx7-0005jC-00 for isis-wg@ietf.org; Sun, 22 Jun 2003 18:04:49 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2003 15:03:02 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5MM4CgE016330; Sun, 22 Jun 2003 15:04:12 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIJ86652; Sun, 22 Jun 2003 14:57:34 -0700 (PDT) Message-ID: <3EF627D9.546996B5@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hannes Gredler CC: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raszuk-isis-bgp-peer-discovery-00.txt References: <3EF61A3E.793B3046@cisco.com> <20030622215748.GA22031@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 00:04:09 +0200 Content-Transfer-Encoding: 7bit Hi, > Hannes Gredler wrote: > > robert, > > pls could you post draft-raszuk-ibgp-auto-mesh-00.txt as well > as i was not able to find it; > > /hannes I did posted it to internet-drafts@ietf.org as well as to the IDR. I hope it will be published soon. In the mean time you can use the below link: ftp://ftp-eng.cisco.com/rraszuk/ibgp-auto-mesh/ R. > Hannes Gredler wrote: > > robert, > > pls could you post draft-raszuk-ibgp-auto-mesh-00.txt as well > as i was not able to find it; > > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 23 02:17:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09911 for ; Mon, 23 Jun 2003 02:17:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKdR-0003LC-0Q; Mon, 23 Jun 2003 02:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKd0-0003Kx-Sv for isis-wg@optimus.ietf.org; Mon, 23 Jun 2003 02:16:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09766 for ; Mon, 23 Jun 2003 02:16:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKci-0007UQ-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 02:16:16 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19UKcX-0007UH-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 02:16:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9249234465; Sun, 22 Jun 2003 22:30:42 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h5N6FFYB005663; Sun, 22 Jun 2003 23:15:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] draft-raszuk-isis-bgp-peer-discovery-00.txt Message-ID: Thread-Topic: [Isis-wg] draft-raszuk-isis-bgp-peer-discovery-00.txt Thread-Index: AcM5AqpD0se3L0+RSJWRsjiI50/cSwATAY4Q From: "Tony Li" To: Cc: Content-Transfer-Encoding: quoted-printable Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Jun 2003 23:15:15 -0700 Content-Transfer-Encoding: quoted-printable Robert, I don't see any provision in here for dealing with route reflectors. Any plans in that direction? Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 23 02:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10441 for ; Mon, 23 Jun 2003 02:29:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKp3-0003nF-Ha; Mon, 23 Jun 2003 02:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKo8-0003mO-4Z for isis-wg@optimus.ietf.org; Mon, 23 Jun 2003 02:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10403 for ; Mon, 23 Jun 2003 02:28:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKo4-0007Wy-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 02:28:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UKnt-0007Wo-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 02:27:49 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2003 23:30:18 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5N6RDqd004583; Sun, 22 Jun 2003 23:27:13 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIK02730; Sun, 22 Jun 2003 23:20:32 -0700 (PDT) Message-ID: <3EF69DBE.885600DD@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li CC: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raszuk-isis-bgp-peer-discovery-00.txt References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 08:27:10 +0200 Content-Transfer-Encoding: 7bit Hmmm why ? I thought that at least section 4.5 & 5.3 provide some basic support for RRs already. Yes I realize that there is some more work required in this area to address various cases folks use reflectors today, but hopefully we could address most of them in the next versions :). ftp://ftp-eng.cisco.com/rraszuk/ibgp-auto-mesh/draft-raszuk-idr-ibgp-auto-mesh-00.txt R. > Tony Li wrote: > > Robert, > > I don't see any provision in here for dealing with route > reflectors. Any plans in that direction? > > Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 23 10:46:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23208 for ; Mon, 23 Jun 2003 10:46:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USa0-0003vK-KQ; Mon, 23 Jun 2003 10:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USZF-0003uh-8t for isis-wg@optimus.ietf.org; Mon, 23 Jun 2003 10:45:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23172 for ; Mon, 23 Jun 2003 10:44:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USYx-0002ej-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 10:44:55 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19USYm-0002eS-00 for isis-wg@ietf.org; Mon, 23 Jun 2003 10:44:44 -0400 Message-ID: From: Jeff Parker To: "'prz@net4u.ch'" Cc: "'Hannes Gredler'" , "'isis-wg@ietf.org'" Subject: RE: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 10:43:08 -0400 > and of course there is no guarantee that (or rather > requirement) that you receive the CSNPs in the same > order they have been sent which could put you > into hot water anyway if you start > to rely on an overlap. > > - tony The issue of unordered CNSPs makes an interesting case. However, I think the difficulty here has nothing to do with the issue of using overlapping LSP IDs vs. abutting LSP IDs. It is not much more difficult to test that two IDs are adjacent than it is to test if they are equal. As Mike pointed out in private mail, overlapping LSP IDs could introduce extra traffic, by causing retransmissions of the LSP whose ID was duplicated. I don't see any advantage to using overlapping LSP IDs. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jun 28 12:39:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27288 for ; Sat, 28 Jun 2003 12:39:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WIj7-0007W0-Dq; Sat, 28 Jun 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WIiU-0007Va-JV for isis-wg@optimus.ietf.org; Sat, 28 Jun 2003 12:38:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27248 for ; Sat, 28 Jun 2003 12:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WIiD-0004FV-00 for isis-wg@ietf.org; Sat, 28 Jun 2003 12:38:05 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19WIi3-0004FL-00 for isis-wg@ietf.org; Sat, 28 Jun 2003 12:37:55 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 28 Jun 2003 12:37:03 -0400 I'm looking at draft-ietf-isis-restart-03.txt, and thinking about generating a set of CSNPs on a LAN interface, and the task of selecting a Temporary DIS (TDIS), discussed in clause c) below. My issue is how much we need to consider the kind of anomaly where not all IS's on a LAN can peer with each other. Page 4 to 5 When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address .... c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers whose IIHs contain the restart TLV, excluding the transmitting router (note the actual DIS is NOT changed by this process.), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Consider the following corner case R is a restarting router running IP A is a low-priority router running IP B is a high-priority router running ISO only All are sending the Restart TLV The problem is that in the best of circumstances, B will not have an adjacency with R or A, and R will be the DIS on the IP subnetwork on the LAN. If you find this a long shot, replace the mismatch over protocol with mismatches due to authentication, IP network matching, Area, etc. I can see the following readings of the clause above Since B did not have an adjacency with R before reboot, it will not send any CSNPs From A's point of view, B is a better candidate. (B is sending the Restart TLV, has higher priority) so A will not send any CSNPs The outcome that we want is for A to become the TDIS, as B's CSNPs are useless. If this is a real problem, here are 3 potential 'solutions': 1) The "restart TLVs" in the clause above must be restart TLVs with RA bit set. This allows us to restrict our selection to routers that respond. There are at least two problems: A) It introduces a new synchronization phase, while A waits to see if B responds, delaying R's return B) This does not deal correctly with the case that we have IS's R.IP and R.ISO rebooting at the same time: B will respond to R.ISO, though this is no help to R.IP. This is even less likely, though possible. Another attack is as follows 2) IS A must consider the possibility of peering between potential TDIS and restarting router This is asking a great deal of A, as it may be hard to predict the rules that B or R would use in checking adjacency. We could use the list of A's peers to select the TDIS from, but peering isn't a transitive relation. And the third choice is: 3) This is a case that is not dealt with. The restarting router will get information on his other interfaces, and A can still maintain his adjacency. I had been planning to implement the test "those routers whose IIHs contain the restart TLV" as a bit in A's list of adjacencies. Each time A gets a Hello from an IS, this bit is reset. This allows rapid generation of the CSNP set, though it may lead to silence sometimes: A peers with B, but R does not, so B does not send. The mirror image is the case that A and B both peer with R, but not with each other. In that case, both will send CSNPs. A fourth choice would be to have on of R's old peers send the CSNPs after a period of silence, but this introduces new states and new difficulties, and another lag at the start of things. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jun 28 22:09:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08286 for ; Sat, 28 Jun 2003 22:09:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WRcj-00069S-Md; Sat, 28 Jun 2003 22:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WRb0-0005zb-PB for isis-wg@optimus.ietf.org; Sat, 28 Jun 2003 22:08:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08235 for ; Sat, 28 Jun 2003 22:07:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WRax-0006fV-00 for isis-wg@ietf.org; Sat, 28 Jun 2003 22:07:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19WRam-0006fO-00 for isis-wg@ietf.org; Sat, 28 Jun 2003 22:07:00 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5T25OIn026820; Sat, 28 Jun 2003 19:05:25 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-28.cisco.com [10.21.96.28]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHO45362; Sat, 28 Jun 2003 18:58:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20030628182558.019080f8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3473955==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 28 Jun 2003 19:05:22 -0700 --=====================_3473955==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jeff - The major theme to what you have below is: If routers on a LAN do not perform DIS election in a consistent manner (whether due to protocol support, authentication, or other issues) then problems arise. The answer to this is: "Of course!". But this has nothing to do with restart - and it is unreasonable to expect the restart draft to deal with this. A quick summary of the state of the protocol on this issue: a)We have RFC 1195 which says that an IP only router and an OSI only router which are adjacent is an unsupported topology. b)We have the multi-topology draft which says you should form an adjacency with all routers on the LAN regardless of what protocols/topologies they support. c)We have the auto encapsulation draft which (along w the ITU) says you must only form an adjacency if you have a protocol in common d)We have real world implementations which sometimes add on other requirements, most notably having a common IP subnet. Now, if you think that we would be better off resolving this issue, I applaud your sentiments. But don't ask the restart draft to solve it. We have neither invented the problem nor made it any worse. We make the assumption that the set of eligible routers participating in what you have called the TDIS election are all following the same rules - as does the normal DIS election. Some more specific comments inline. Les At 12:37 PM 6/28/2003 -0400, Jeff Parker wrote: >I'm looking at draft-ietf-isis-restart-03.txt, and thinking about >generating a set of CSNPs on a LAN interface, and the task of >selecting a Temporary DIS (TDIS), discussed in clause c) below. > >My issue is how much we need to consider the kind of anomaly >where not all IS's on a LAN can peer with each other. > >Page 4 to 5 > > When the neighbor of a (re)starting router receives an IIH with the > restart TLV having the RR bit set, if there exists on this interface > an adjacency in state "Up" with the same System ID, and in the case > of a LAN circuit, with the same source LAN address .... > > c) if the corresponding interface is a Point-to-Point interface, or > if the receiving router has the highest LnRouterPriority (with > highest source MAC address breaking ties) among those routers > whose IIHs contain the restart TLV, excluding the transmitting > router (note the actual DIS is NOT changed by this process.), > initiate the transmission over the corresponding interface of a > complete set of CSNPs, and set SRMflags on the corresponding > interface for all LSPs in the local LSP database. > >Consider the following corner case > > R is a restarting router running IP > A is a low-priority router running IP > B is a high-priority router running ISO only > > All are sending the Restart TLV > >The problem is that in the best of circumstances, B will >not have an adjacency with R or A, and R will be the DIS >on the IP subnetwork on the LAN. > >If you find this a long shot, replace the mismatch over >protocol with mismatches due to authentication, IP network >matching, Area, etc. > >I can see the following readings of the clause above > > Since B did not have an adjacency with R before > reboot, it will not send any CSNPs This is indeed true. The requirement that applies to 4.2.1a,b,c is that the neighbor have an adjacency to the restarting router in the UP state. If it does not, even though the neighbor is restart capable it will not adhere to paragraph "c". The draft says: "Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH." > From A's point of view, B is a better candidate. > (B is sending the Restart TLV, has higher priority) > so A will not send any CSNPs In your mismatched protocol example, A will not have an adjacency with B in the UP state so A will not consider B as a candidate for TDIS (or for DIS for that matter). >The outcome that we want is for A to become the TDIS, as >B's CSNPs are useless. If this is a real problem, here >are 3 potential 'solutions': > > 1) The "restart TLVs" in the clause above must be > restart TLVs with RA bit set. > >This allows us to restrict our selection to routers that >respond. There are at least two problems: > > A) It introduces a new synchronization phase, while A waits > to see if B responds, delaying R's return > > B) This does not deal correctly with the case that we have > IS's R.IP and R.ISO rebooting at the same time: B will > respond to R.ISO, though this is no help to R.IP. This is > even less likely, though possible. > >Another attack is as follows > > 2) IS A must consider the possibility of peering between > potential TDIS and restarting router > >This is asking a great deal of A, as it may be hard to >predict the rules that B or R would use in checking >adjacency. We could use the list of A's peers to select >the TDIS from, but peering isn't a transitive relation. The same problem exists in normal DIS election. If A has an adjacency to both B and R, then A assumes that transitivity on the LAN exists and so it can safely consider both B and R as candidates in its DIS election. If the transitive assumption proves false, we can have problems, but not because of restart. >And the third choice is: > > 3) This is a case that is not dealt with. > The restarting router will get information on > his other interfaces, and A can still maintain > his adjacency. > >I had been planning to implement the test "those routers >whose IIHs contain the restart TLV" as a bit in A's list >of adjacencies. Each time A gets a Hello from an IS, this >bit is reset. This allows rapid generation of the CSNP >set, though it may lead to silence sometimes: A peers >with B, but R does not, so B does not send. The mirror >image is the case that A and B both peer with R, but not >with each other. In that case, both will send CSNPs. Which would still work - it would just be less efficient. In actual practice, if no topology changes have happened during the time interval it took R to restart, then getting a set of CSNPs from only one neighbor on any circuit would prove sufficient - but of course R has no way to know which neighbor to choose, so we rely on all of our neighbors. In most cases it's overkill, but it is necessary to make the process reliable. >A fourth choice would be to have on of R's old peers >send the CSNPs after a period of silence, but this >introduces new states and new difficulties, and another >lag at the start of things. > >- jeff parker >- axiowave networks > > > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_3473955==_.ALT Content-Type: text/html; charset="us-ascii"
Jeff -

The major theme to what you have below is:

If routers on a LAN do not perform DIS election in a consistent manner (whether due to protocol support, authentication, or other issues) then problems arise.

The answer to this is: "Of course!". But this has nothing to do with restart - and it is unreasonable to expect the restart draft to deal with this.

A quick summary of the state of the protocol on this issue:

a)We have RFC 1195 which says that an IP only router and an OSI only router which are adjacent is an unsupported topology.
b)We have the multi-topology draft which says you should form an adjacency with all routers on the LAN regardless of what protocols/topologies they support.
c)We have the auto encapsulation draft which (along w the ITU) says you must only form an adjacency if you have a protocol in common
d)We have real world implementations which sometimes add on other requirements, most notably having a common IP subnet.

Now, if you think that we would be better off resolving this issue, I applaud your sentiments. But don't ask the restart draft to solve it. We have neither invented the problem nor made it any worse. We make the assumption that the set of eligible routers participating in what you have called the TDIS election are all following the same rules - as does the normal DIS election.

Some more specific comments inline.

   Les

At 12:37 PM 6/28/2003 -0400, Jeff Parker wrote:
I'm looking at draft-ietf-isis-restart-03.txt, and thinking about
generating a set of CSNPs on a LAN interface, and the task of
selecting a Temporary DIS (TDIS), discussed in clause c) below. 

My issue is how much we need to consider the kind of anomaly
where not all IS's on a LAN can peer with each other. 

Page 4 to 5

   When the neighbor of a (re)starting router receives an IIH with the
   restart TLV having the RR bit set, if there exists on this interface
   an adjacency in state "Up" with the same System ID, and in the case
   of a LAN circuit, with the same source LAN address ....

  c) if the corresponding interface is a Point-to-Point interface, or
     if the receiving router has the highest LnRouterPriority (with
     highest source MAC address breaking ties) among those routers
     whose IIHs contain the restart TLV, excluding the transmitting
     router (note the actual DIS is NOT changed by this process.),
     initiate the transmission over the corresponding interface of a
     complete set of CSNPs, and set SRMflags on the corresponding
     interface for all LSPs in the local LSP database.

Consider the following corner case

        R is a restarting router running IP
        A is a low-priority router running IP
        B is a high-priority router running ISO only

        All are sending the Restart TLV

The problem is that in the best of circumstances, B will
not have an adjacency with R or A, and R will be the DIS
on the IP subnetwork on the LAN. 

If you find this a long shot, replace the mismatch over
protocol with mismatches due to authentication, IP network
matching, Area, etc.

I can see the following readings of the clause above

        Since B did not have an adjacency with R before
        reboot, it will not send any CSNPs

This is indeed true. The requirement that applies to 4.2.1a,b,c is that the neighbor have an adjacency to the restarting router in the UP state. If it does not, even though the neighbor is restart capable it will not adhere to paragraph "c". The draft says:
"Otherwise (i.e. if there was no adjacency in the "UP" state to the
   system ID in question), process the IIH as normal by reinitializing
   the adjacency, and setting the RA bit in the returned IIH."



        From A's point of view, B is a better candidate.
        (B is sending the Restart TLV, has higher priority)
        so A will not send any CSNPs

In your mismatched protocol example, A will not have an adjacency with B in the UP state so A will not consider B as a candidate for TDIS (or for DIS for that matter).

The outcome that we want is for A to become the TDIS, as
B's CSNPs are useless.  If this is a real problem, here
are 3 potential 'solutions':

        1) The "restart TLVs" in the clause above must be
        restart TLVs with RA bit set. 

This allows us to restrict our selection to routers that
respond.  There are at least two problems:

  A) It introduces a new synchronization phase, while A waits
  to see if B responds, delaying R's return

  B) This does not deal correctly with the case that we have
  IS's R.IP and R.ISO rebooting at the same time: B will
  respond to R.ISO, though this is no help to R.IP.  This is
  even less likely, though possible.  

Another attack is as follows

        2) IS A must consider the possibility of peering between
        potential TDIS and restarting router

This is asking a great deal of A, as it may be hard to
predict the rules that B or R would use in checking
adjacency.  We could use the list of A's peers to select
the TDIS from, but peering isn't a transitive relation. 

The same problem exists in normal DIS election. If A has an adjacency to both B and R, then A assumes that transitivity on the LAN exists and so it can safely consider both B and R as candidates in its DIS election. If the transitive assumption proves false, we can have problems, but not because of restart.

And the third choice is:

        3) This is a case that is not dealt with.
        The restarting router will get information on
        his other interfaces, and A can still maintain
        his adjacency. 

I had been planning to implement the test "those routers
whose IIHs contain the restart TLV" as a bit in A's list
of adjacencies.  Each time A gets a Hello from an IS, this
bit is reset.  This allows rapid generation of the CSNP
set, though it may lead to silence sometimes: A peers
with B, but R does not, so B does not send.  The mirror
image is the case that A and B both peer with R, but not
with each other.  In that case, both will send CSNPs. 

Which would still work - it would just be less efficient. In actual practice, if no topology changes have happened during the time interval it took R to restart, then getting a set of CSNPs from only one neighbor on any circuit would prove sufficient - but of course R has no way to know which neighbor to choose, so we rely on all of our neighbors. In most cases it's overkill, but it is necessary to make the process reliable.

A fourth choice would be to have on of R's old peers
send the CSNPs after a period of silence, but this
introduces new states and new difficulties, and another
lag at the start of things.   

- jeff parker
- axiowave networks
 

 

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_3473955==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 07:30:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10395 for ; Mon, 30 Jun 2003 07:30:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwrA-0000cq-RY; Mon, 30 Jun 2003 07:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwqS-0000Z6-B7 for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 07:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10247 for ; Mon, 30 Jun 2003 07:29:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WwqR-0005uS-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 07:29:15 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19WwqH-0005tm-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 07:29:05 -0400 Received: from there (ams-clip-vpn-dhcp4133.cisco.com [10.61.80.36]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with SMTP id h5UBS0p08878 for ; Mon, 30 Jun 2003 13:28:00 +0200 (CEST) Message-Id: <200306301128.h5UBS0p08878@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: isis-wg@ietf.org Subject: [Isis-wg] Agenda for Vienna ? X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 13:27:57 +0200 Content-Transfer-Encoding: quoted-printable Folks, do we have an agenda for Vienna meeting ? thanks. s. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 08:13:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15260 for ; Mon, 30 Jun 2003 08:13:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxWn-0003Yf-7E; Mon, 30 Jun 2003 08:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxWE-0003XY-Ry for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 08:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15194 for ; Mon, 30 Jun 2003 08:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxVy-0006R1-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 08:12:10 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19WxVo-0006QR-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 08:12:00 -0400 Received: (qmail 5789 invoked from network); 30 Jun 2003 12:04:43 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.103) by 172.16.36.12 with SMTP; 30 Jun 2003 12:04:43 -0000 Message-ID: <3F00275A.9080807@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefano previdi CC: isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? References: <200306301128.h5UBS0p08878@strange-brew.cisco.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 14:04:42 +0200 Content-Transfer-Encoding: 7bit stefano previdi wrote: >Folks, > >do we have an agenda for Vienna meeting ? > >thanks. > >s. > > Nobody brought any issues/presentations up so unless there are any, I didn't even plan for a session -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 10:36:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27908 for ; Mon, 30 Jun 2003 10:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WzlA-0001zI-M3; Mon, 30 Jun 2003 10:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WzkI-0001tG-RT for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 10:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27561 for ; Mon, 30 Jun 2003 10:34:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WzYl-00016Z-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 10:23:11 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19WzYX-00015y-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 10:22:57 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 10:21:54 -0400 > Jeff - > The major theme to what you have below is: > If routers on a LAN do not perform DIS election in a consistent manner (whether due to protocol support, > authentication, or other issues) then problems arise. > The answer to this is: "Of course!". > But this has nothing to do with restart - > and it is unreasonable to expect the restart draft to deal with this. From A's point of view, B is a better candidate. (B is sending the Restart TLV, has higher priority) so A will not send any CSNPs > In your mismatched protocol example, A will not have an adjacency > with B in the UP state so A will not consider B as a candidate > for TDIS (or for DIS for that matter). Les - I agree that the draft cannot fix that which is broken someplace else. However, even your comment above refers to the "common sense" algorithm that I wanted to implement, but seemed ruled out by the text of the draft. The text suggests we must start with all routers on the LAN, while starting with the neighbors of A is a faster algorithm, and more likely to reach the right result. We could replace "among those routers" in the text below c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers whose IIHs contain the restart TLV, excluding the transmitting router (note the actual DIS is NOT changed by this process.), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. with "among those routers adjacent to the neighbor". If we give the assisting router a symbolic name (such as A above), this would be made clearer: "among those routers adjacent to the neighbor A." - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 11:55:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02549 for ; Mon, 30 Jun 2003 11:55:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0ze-00072F-F1; Mon, 30 Jun 2003 11:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0yu-0006wn-3D for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 11:54:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02353 for ; Mon, 30 Jun 2003 11:54:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0iK-0001ud-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 11:37:08 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19X0i7-0001uK-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 11:36:55 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5UFZRO0013274; Mon, 30 Jun 2003 08:35:27 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-673.cisco.com [10.21.82.161]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHP00791; Mon, 30 Jun 2003 08:27:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20030630082910.018f6558@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: RE: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1071310==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 08:35:21 -0700 --=====================_1071310==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:21 AM 6/30/2003 -0400, Jeff Parker wrote: > > > Jeff - > > > The major theme to what you have below is: > > > If routers on a LAN do not perform DIS election in a consistent manner >(whether due to protocol support, > > authentication, or other issues) then problems arise. > > > The answer to this is: "Of course!". > > But this has nothing to do with restart - > > and it is unreasonable to expect the restart draft to deal with this. > > From A's point of view, B is a better candidate. > (B is sending the Restart TLV, has higher priority) > so A will not send any CSNPs > > > > In your mismatched protocol example, A will not have an adjacency > > with B in the UP state so A will not consider B as a candidate > > for TDIS (or for DIS for that matter). > >Les - > I agree that the draft cannot fix that which is broken >someplace else. However, even your comment above refers to the >"common sense" algorithm that I wanted to implement, but seemed >ruled out by the text of the draft. > > The text suggests we must start with all routers on the LAN, >while starting with the neighbors of A is a faster algorithm, and >more likely to reach the right result. > > We could replace "among those routers" in the text below > > c) if the corresponding interface is a Point-to-Point interface, or > if the receiving router has the highest LnRouterPriority (with > highest source MAC address breaking ties) among those routers > whose IIHs contain the restart TLV, excluding the transmitting > router (note the actual DIS is NOT changed by this process.), > initiate the transmission over the corresponding interface of a > complete set of CSNPs, and set SRMflags on the corresponding > interface for all LSPs in the local LSP database. > >with "among those routers adjacent to the neighbor". If we give >the assisting router a symbolic name (such as A above), this would >be made clearer: "among those routers adjacent to the neighbor A." Jeff - In the upcoming Version 4 of the draft this text has already been changed to read: among those routers to which the receiving router has an adjacency in state "Up" on this interface whose IIHs contain the restart TLV, I think this is always what was intended but was not stated as explictly as it could have been i.e we never intended the "TDIS" election to include routers for which no adjacency in the UP state existed - whatever the reason. . Because your original mail discussed a variety of complex solutions, I didn't realize that all you were concerned about was a lack of explicitness in the text. Hopefully this resolves the issue. Thanx. Les >- jeff parker --=====================_1071310==_.ALT Content-Type: text/html; charset="us-ascii" At 10:21 AM 6/30/2003 -0400, Jeff Parker wrote:
 
> Jeff -

> The major theme to what you have below is:

> If routers on a LAN do not perform DIS election in a consistent manner
(whether due to protocol support,
> authentication, or other issues) then problems arise.

> The answer to this is: "Of course!".
> But this has nothing to do with restart -
> and it is unreasonable to expect the restart draft to deal with this.

         From A's point of view, B is a better candidate.
        (B is sending the Restart TLV, has higher priority)
        so A will not send any CSNPs


> In your mismatched protocol example, A will not have an adjacency
> with B in the UP state so A will not consider B as a candidate
> for TDIS (or for DIS for that matter).

Les -
        I agree that the draft cannot fix that which is broken
someplace else.  However, even your comment above refers to the
"common sense" algorithm that I wanted to implement, but seemed
ruled out by the text of the draft.

        The text suggests we must start with all routers on the LAN,
while starting with the neighbors of A is a faster algorithm, and
more likely to reach the right result.

        We could replace "among those routers" in the text below

  c) if the corresponding interface is a Point-to-Point interface, or
     if the receiving router has the highest LnRouterPriority (with
     highest source MAC address breaking ties) among those routers
     whose IIHs contain the restart TLV, excluding the transmitting
     router (note the actual DIS is NOT changed by this process.),
     initiate the transmission over the corresponding interface of a
     complete set of CSNPs, and set SRMflags on the corresponding
     interface for all LSPs in the local LSP database.

with "among those routers adjacent to the neighbor".  If we give
the assisting router a symbolic name (such as A above), this would
be made clearer: "among those routers adjacent to the neighbor A."

Jeff -

In the upcoming Version 4 of the draft this text has already been changed to read:
 among those routers to which the receiving router has an adjacency in state "Up" on this
 interface whose IIHs contain the restart TLV,
I think this is always what was intended but was not stated as explictly as it could have been i.e we never intended the "TDIS" election to include routers for which no adjacency in the UP state existed - whatever the reason.
.
Because your original mail discussed a variety of complex solutions, I didn't realize that all you were concerned about was a lack of explicitness in the text.

Hopefully this resolves the issue.

Thanx.

   Les


- jeff parker
--=====================_1071310==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 12:41:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05132 for ; Mon, 30 Jun 2003 12:41:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1iA-0002NC-At; Mon, 30 Jun 2003 12:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1hT-0002LO-7q for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 12:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05022 for ; Mon, 30 Jun 2003 12:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1ff-0002Vd-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 12:38:27 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19X1fP-0002Uq-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 12:38:12 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h5UGZ2h23344; Mon, 30 Jun 2003 18:35:02 +0200 From: Hannes Gredler To: Tony Przygienda Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? Message-ID: <20030630163502.GA23319@juniper.net> References: <200306301128.h5UBS0p08878@strange-brew.cisco.com> <3F00275A.9080807@xebeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F00275A.9080807@xebeo.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 18:35:02 +0200 On Mon, Jun 30, 2003 at 02:04:42PM +0200, Tony Przygienda wrote: | stefano previdi wrote: | | >Folks, | > | >do we have an agenda for Vienna meeting ? | > | >thanks. | > | >s. | > | > | Nobody brought any issues/presentations up so unless there are any, | I didn't even plan for a session seems we have a slot: TUESDAY, July 15, 2003 1415-1515 Afternoon Sessions II Hall GH RTG isis IS-IS for IP Internets WG -- /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 12:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05407 for ; Mon, 30 Jun 2003 12:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1mz-0002kF-A7; Mon, 30 Jun 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1mM-0002jN-VC for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 12:45:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05363 for ; Mon, 30 Jun 2003 12:45:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1mK-0002a4-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 12:45:20 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19X1m9-0002Zb-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 12:45:10 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 12:44:05 -0400 > In the upcoming Version 4 of the draft this text has already been changed to read: > among those routers to which the receiving router has an adjacency in state "Up" on this > interface whose IIHs contain the restart TLV, Les - Thanks - that addresses my concern. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 13:19:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06970 for ; Mon, 30 Jun 2003 13:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2Iv-0004qY-LY; Mon, 30 Jun 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X2Ia-0004pn-9c for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 13:18:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06882 for ; Mon, 30 Jun 2003 13:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X2IX-0002sf-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 13:18:37 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19X2IN-0002rp-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 13:18:27 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 00401A4E48A; Mon, 30 Jun 2003 10:17:55 -0700 (PDT) To: prz@xebeo.com Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-reply-to: Mail from Tony Przygienda dated Mon, 30 Jun 2003 14:04:42 +0200 <3F00275A.9080807@xebeo.com> From: Naiming Shen Message-Id: <20030630171756.00401A4E48A@prattle.redback.com> Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 10:17:55 -0700 tony, could you alloc 10 min for this one if you are going to have a session, thanks. folks, this draft is the isis part of the IGP capability, please review and comment, thanks. http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt ] stefano previdi wrote: ] ] >Folks, ] > ] >do we have an agenda for Vienna meeting ? ] > ] >thanks. ] > ] >s. ] > ] > ] Nobody brought any issues/presentations up so unless there are any, ] I didn't even plan for a session ] ] -- tony ] ] > ] > ] ] ] ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jun 30 16:22:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14532 for ; Mon, 30 Jun 2003 16:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X5A0-0006eA-Or; Mon, 30 Jun 2003 16:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X59E-0006d0-IB for isis-wg@optimus.ietf.org; Mon, 30 Jun 2003 16:21:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14480 for ; Mon, 30 Jun 2003 16:21:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X59C-00041v-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 16:21:10 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19X592-00041b-00 for isis-wg@ietf.org; Mon, 30 Jun 2003 16:21:00 -0400 Received: (qmail 5192 invoked from network); 30 Jun 2003 20:19:17 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.103) by 172.16.36.12 with SMTP; 30 Jun 2003 20:19:17 -0000 Message-ID: <3F009B3A.6090801@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naiming Shen CC: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? References: <20030630171756.00401A4E48A@prattle.redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 30 Jun 2003 22:19:06 +0200 Content-Transfer-Encoding: 7bit Naiming Shen wrote: >tony, > >could you alloc 10 min for this one if you are going to have a >session, thanks. > >folks, > >this draft is the isis part of the IGP capability, please review >and comment, thanks. > >http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt > > sure, ok, so we have a session then and I'm still open for requests for agenda items =- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg