From isis-wg-admin@spider.juniper.net Tue May 1 04:45:22 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21779 for ; Tue, 1 May 2001 04:45:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA11484; Tue, 1 May 2001 02:20:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA11469 for ; Tue, 1 May 2001 02:19:07 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f418Wxb64859 for ; Tue, 1 May 2001 01:32:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com ([10.49.188.189]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA20431; Tue, 1 May 2001 09:37:09 +0100 (BST) Message-Id: <4.3.2.7.2.20010501092926.0356f298@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Learman , oran@cisco.com From: mike shand Subject: Re: [Isis-wg] downstream paths? Cc: Radia Perlman , isis-wg@juniper.net, sivaa@indiatimes.com In-Reply-To: <4.3.2.7.2.20010430182119.019c0548@dingdong.cisco.com> References: <200104301938.PAA11826@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 01 May 2001 09:36:24 +0100 This was another of those things which it was easier to allow to be put in there than it was to argue against it. As I recall it was a guy called Mikel Silvest (I may have the spelling wrong) who wanted this. We had already had to remove the description of the SPF algorithm from the normative text into a non-normative appendix (since from an interoperability point of view it doesn't matter WHAT the algorithm is, it only matters that it gives the same results). Dave might remember more. As far as I am aware, nobody has ever attempted to implement this. Yes, the idea I think was to be able to do better load balancing, but I was never convinced it was a good idea. At 18:31 30/04/2001 -0400, Jeff Learman wrote: >Radia, > >Thanks for the clarification. > >Your interpretation matches the only interpretation I have ever >been able to glean from the spec. I am at a loss for why anyone >would bother to do more work to get less optimal routes, other >than to be able to do load balancing in more circumstances. >(Whether that kind of LB would actually be a good idea is another >question.) > >I can't answer whether this is implemented in any integrated IS-IS >implementations, but I will be surprised if it is. If it was, it >could not be used in conjunction with reverse path filtering, >of course. > >Regards, >Jeff > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: > >OK. Reading Jeff Parker's reply I now understand, but perhaps > >it's worth having a 2nd person explain it. > > > >I didn't remember this from IS-IS at all (I assume > >it got put in by ISO and wasn't in the original DECnet > >Phase V routing algorithm), but apparently (based on > >the section quoted by Jeff) you're > >allowed to forward a packet destined to D to neighbor N even if > >N isn't on a minimal path from you to D, but instead neighbor N > >is closer to D than you are. In other words, you have a path through > >neighbor N1 to D that is of cost 50, and that's your best path. > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > >If you forward through N your path will be 53, clearly worse than > >your path through N1, but since N is closer to D than you (N is > >48 away, you're 50 away), you're allowed to forward to N. > > > >A neighbor closer to D than you is "downstream". So N (as well as N1) > >would be downstream. > > > >The normal Dijkstra calculation wouldn't tell you all neighbors closer > >to D than you. The only way to get this is to calculate Dijkstra > >from the point of view of each neighbor. That's why, if you have k > >neighbors, you'd have to calculate Dijkstra from your own point of > >view, plus from the point of view of each neighbor (to find out, for > >each destination, which of your neighbors is closer to the destination > >than you are). > > > >And with multiple metrics, you'd have to multiply the number of Dijkstra > >calculations by the number of metrics (I never did like the multiple > >metric thing, especially the way ISO specified it...that you leave out > >links that don't advertise that metric so you're calculating an "optimal" > >path based on a subset of the links!). > > > >So that explains why the section you quoted says if there are 4 > >metrics, and you want to "calculate downstream paths) i.e., find out > >which neighbors are closer than you for each destination), you > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > >I always thought the multiple metrics were not worth the extra > >calculation and configuration (and were actually quite dangerous > >given how ISO specified it since it's very nonintuitive why you > >might get really horrible routes if you use any metric that isn't > >universally supported on every link). I'd think this "calculating > >downstream paths" would also not be worth the extra computation > >and storage. Does any IS-IS implementation bother with this > >"downstream paths" thing? > > > >Radia > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 1 10:34:34 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28777 for ; Tue, 1 May 2001 10:34:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12961; Tue, 1 May 2001 08:13:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12949 for ; Tue, 1 May 2001 08:12:45 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f41EQYb71697 for ; Tue, 1 May 2001 07:26:35 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'isis-wg@juniper.net'" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D24B.523AA890" Subject: [Isis-wg] draft-ietf-isis-wg-mib-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 1 May 2001 10:30:51 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D24B.523AA890 Content-Type: text/plain; charset="iso-8859-1" A copy of the source to the isis mib suitable for feeding to a mib compiler should now be accessible at ftp.axiowave.com. This DNS name should resolve to 209.6.34.3. The URL for the draft, with words, page numbers, etc. is on the IETF site at http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-04.txt Please let me know about any questions or issues. The changes in this version are described at the top of the mib file, and a visible in either version. - jeff parker - axiowave networks ------_=_NextPart_001_01C0D24B.523AA890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-isis-wg-mib-04.txt

A copy of the source to the isis mib suitable for = feeding to a mib compiler should
now be accessible at ftp.axiowave.com.  This = DNS name should resolve to 209.6.34.3. 

The URL for the draft, with words, page numbers, etc. = is on the IETF site at
        =         http://www.ietf.org/internet-drafts/draft-ietf-isis-wg= -mib-04.txt

Please let me know about any questions or = issues.  The changes in this version
are described at the top of the mib file, and a = visible in either version. 

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0D24B.523AA890-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 1 13:45:56 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05433 for ; Tue, 1 May 2001 13:45:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13753; Tue, 1 May 2001 11:25:06 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13738 for ; Tue, 1 May 2001 11:24:37 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA08421; Tue, 1 May 2001 10:42:35 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id KAA20373; Tue, 1 May 2001 10:42:34 -0700 (PDT) Message-Id: <200105011742.KAA20373@cirrus.juniper.net> From: Dave Katz To: mshand@cisco.com CC: jlearman@cisco.com, oran@cisco.com, Radia.Perlman@Sun.COM, isis-wg@juniper.net, sivaa@indiatimes.com In-reply-to: <4.3.2.7.2.20010501092926.0356f298@jaws.cisco.com> (message from mike shand on Tue, 01 May 2001 09:36:24 +0100) Subject: Re: [Isis-wg] downstream paths? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 1 May 2001 10:42:34 -0700 (PDT) In theory I suppose this could be used to provide potentially feasible "standby" routes that could be quickly plugged in when link failure is detected locally, thus reducing the black hole period by some nominal amount, at the cost of additional background calculation. This kind of scheme is used in EIGRP to determine feasible successors prior to the failure of the primary path, in order to avoid entering Active state. It can also be used for unequal cost load balancing, as mentioned. It makes a lot more sense in EIGRP's case, since it takes no more computation to determine the feasible successors (the neighbors are already telling you their path cost), and since the cost of having to find a new path from scratch is relatively high. --Dave X-JNPR-Received-From: outside X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 From: mike shand Cc: Radia Perlman , isis-wg@juniper.net, sivaa@indiatimes.com References: <200104301938.PAA11826@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 01 May 2001 09:36:24 +0100 This was another of those things which it was easier to allow to be put in there than it was to argue against it. As I recall it was a guy called Mikel Silvest (I may have the spelling wrong) who wanted this. We had already had to remove the description of the SPF algorithm from the normative text into a non-normative appendix (since from an interoperability point of view it doesn't matter WHAT the algorithm is, it only matters that it gives the same results). Dave might remember more. As far as I am aware, nobody has ever attempted to implement this. Yes, the idea I think was to be able to do better load balancing, but I was never convinced it was a good idea. At 18:31 30/04/2001 -0400, Jeff Learman wrote: >Radia, > >Thanks for the clarification. > >Your interpretation matches the only interpretation I have ever >been able to glean from the spec. I am at a loss for why anyone >would bother to do more work to get less optimal routes, other >than to be able to do load balancing in more circumstances. >(Whether that kind of LB would actually be a good idea is another >question.) > >I can't answer whether this is implemented in any integrated IS-IS >implementations, but I will be surprised if it is. If it was, it >could not be used in conjunction with reverse path filtering, >of course. > >Regards, >Jeff > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: > >OK. Reading Jeff Parker's reply I now understand, but perhaps > >it's worth having a 2nd person explain it. > > > >I didn't remember this from IS-IS at all (I assume > >it got put in by ISO and wasn't in the original DECnet > >Phase V routing algorithm), but apparently (based on > >the section quoted by Jeff) you're > >allowed to forward a packet destined to D to neighbor N even if > >N isn't on a minimal path from you to D, but instead neighbor N > >is closer to D than you are. In other words, you have a path through > >neighbor N1 to D that is of cost 50, and that's your best path. > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > >If you forward through N your path will be 53, clearly worse than > >your path through N1, but since N is closer to D than you (N is > >48 away, you're 50 away), you're allowed to forward to N. > > > >A neighbor closer to D than you is "downstream". So N (as well as N1) > >would be downstream. > > > >The normal Dijkstra calculation wouldn't tell you all neighbors closer > >to D than you. The only way to get this is to calculate Dijkstra > >from the point of view of each neighbor. That's why, if you have k > >neighbors, you'd have to calculate Dijkstra from your own point of > >view, plus from the point of view of each neighbor (to find out, for > >each destination, which of your neighbors is closer to the destination > >than you are). > > > >And with multiple metrics, you'd have to multiply the number of Dijkstra > >calculations by the number of metrics (I never did like the multiple > >metric thing, especially the way ISO specified it...that you leave out > >links that don't advertise that metric so you're calculating an "optimal" > >path based on a subset of the links!). > > > >So that explains why the section you quoted says if there are 4 > >metrics, and you want to "calculate downstream paths) i.e., find out > >which neighbors are closer than you for each destination), you > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > >I always thought the multiple metrics were not worth the extra > >calculation and configuration (and were actually quite dangerous > >given how ISO specified it since it's very nonintuitive why you > >might get really horrible routes if you use any metric that isn't > >universally supported on every link). I'd think this "calculating > >downstream paths" would also not be worth the extra computation > >and storage. Does any IS-IS implementation bother with this > >"downstream paths" thing? > > > >Radia > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 1 19:17:59 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12233 for ; Tue, 1 May 2001 19:17:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA15053; Tue, 1 May 2001 16:52:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA15041 for ; Tue, 1 May 2001 16:51:59 -0700 (PDT) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f41N5jb95152; Tue, 1 May 2001 16:05:45 -0700 (PDT) X-JNPR-Received-From: outside Received: from DIMA1 ([47.184.55.188]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id TAA01051; Tue, 1 May 2001 19:10:03 -0400 From: "Dmitri Krioukov" To: "Dave Katz" , Cc: , , , , Subject: RE: [Isis-wg] downstream paths? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200105011742.KAA20373@cirrus.juniper.net> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 1 May 2001 19:10:03 -0400 Content-Transfer-Encoding: 7bit Was this idea (of "standby" routes) in anyone's mind when this text was put in, though? -- dima. > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Dave Katz > Sent: Tuesday, May 01, 2001 1:43 PM > To: mshand@cisco.com > Cc: jlearman@cisco.com; oran@cisco.com; Radia.Perlman@Sun.COM; > isis-wg@juniper.net; sivaa@indiatimes.com > Subject: Re: [Isis-wg] downstream paths? > > > In theory I suppose this could be used to provide potentially feasible > "standby" routes that could be quickly plugged in when link failure is > detected locally, thus reducing the black hole period by some nominal > amount, at the cost of additional background calculation. > > This kind of scheme is used in EIGRP to determine feasible successors > prior to the failure of the primary path, in order to avoid entering > Active state. It can also be used for unequal cost load balancing, as > mentioned. It makes a lot more sense in EIGRP's case, since it takes > no more computation to determine the feasible successors (the > neighbors are already telling you their path cost), and since the cost > of having to find a new path from scratch is relatively high. > > --Dave > > X-JNPR-Received-From: outside > X-Sender: mshand@jaws.cisco.com > X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 > From: mike shand > Cc: Radia Perlman , isis-wg@juniper.net, > sivaa@indiatimes.com > References: <200104301938.PAA11826@bcn.East.Sun.COM> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: > , > > List-Archive: > Date: Tue, 01 May 2001 09:36:24 +0100 > > This was another of those things which it was easier to allow > to be put in > there than it was to argue against it. As I recall it was a guy called > Mikel Silvest (I may have the spelling wrong) who wanted this. We had > already had to remove the description of the SPF algorithm from the > normative text into a non-normative appendix (since from an > interoperability point of view it doesn't matter WHAT the > algorithm is, it > only matters that it gives the same results). > > Dave might remember more. > > As far as I am aware, nobody has ever attempted to implement this. > > Yes, the idea I think was to be able to do better load > balancing, but I was > never convinced it was a good idea. > > > At 18:31 30/04/2001 -0400, Jeff Learman wrote: > > >Radia, > > > >Thanks for the clarification. > > > >Your interpretation matches the only interpretation I have ever > >been able to glean from the spec. I am at a loss for why anyone > >would bother to do more work to get less optimal routes, other > >than to be able to do load balancing in more circumstances. > >(Whether that kind of LB would actually be a good idea is another > >question.) > > > >I can't answer whether this is implemented in any integrated IS-IS > >implementations, but I will be surprised if it is. If it was, it > >could not be used in conjunction with reverse path filtering, > >of course. > > > >Regards, > >Jeff > > > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for > Networking wrote: > > >OK. Reading Jeff Parker's reply I now understand, but perhaps > > >it's worth having a 2nd person explain it. > > > > > >I didn't remember this from IS-IS at all (I assume > > >it got put in by ISO and wasn't in the original DECnet > > >Phase V routing algorithm), but apparently (based on > > >the section quoted by Jeff) you're > > >allowed to forward a packet destined to D to neighbor N even if > > >N isn't on a minimal path from you to D, but instead neighbor N > > >is closer to D than you are. In other words, you have a path through > > >neighbor N1 to D that is of cost 50, and that's your best path. > > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > > >If you forward through N your path will be 53, clearly worse than > > >your path through N1, but since N is closer to D than you (N is > > >48 away, you're 50 away), you're allowed to forward to N. > > > > > >A neighbor closer to D than you is "downstream". So N (as > well as N1) > > >would be downstream. > > > > > >The normal Dijkstra calculation wouldn't tell you all > neighbors closer > > >to D than you. The only way to get this is to calculate Dijkstra > > >from the point of view of each neighbor. That's why, if you have k > > >neighbors, you'd have to calculate Dijkstra from your own point of > > >view, plus from the point of view of each neighbor (to find out, for > > >each destination, which of your neighbors is closer to the > destination > > >than you are). > > > > > >And with multiple metrics, you'd have to multiply the > number of Dijkstra > > >calculations by the number of metrics (I never did like the multiple > > >metric thing, especially the way ISO specified it...that > you leave out > > >links that don't advertise that metric so you're > calculating an "optimal" > > >path based on a subset of the links!). > > > > > >So that explains why the section you quoted says if there are 4 > > >metrics, and you want to "calculate downstream paths) i.e., find out > > >which neighbors are closer than you for each destination), you > > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > > > >I always thought the multiple metrics were not worth the extra > > >calculation and configuration (and were actually quite dangerous > > >given how ISO specified it since it's very nonintuitive why you > > >might get really horrible routes if you use any metric that isn't > > >universally supported on every link). I'd think this "calculating > > >downstream paths" would also not be worth the extra computation > > >and storage. Does any IS-IS implementation bother with this > > >"downstream paths" thing? > > > > > >Radia > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 08:02:08 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06947 for ; Wed, 2 May 2001 08:02:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA18224; Wed, 2 May 2001 05:38:36 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA18212 for ; Wed, 2 May 2001 05:37:37 -0700 (PDT) Received: from EXCHANGE.kerenix.com ([212.150.1.82]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42BpEb11091 for ; Wed, 2 May 2001 04:51:15 -0700 (PDT) X-JNPR-Received-From: outside Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <22WLZA10>; Wed, 2 May 2001 14:57:07 +0300 Message-ID: <2B15221907365C468941FDFC02C8776932391B@EXCHANGE.kerenix.com> From: Talmon_Reiss To: "IS-IS Mailing List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Isis-wg] Operation of P-toP links Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 May 2001 14:57:06 +0300 Hi I have some questions regarding the operation of P-to-P links in IS-IS: After the establishment of a P-to-P adjacency what exactly happens wrt to LSP transmission ? Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? What is the purpose of the partialSNPInterval timer? When is it used? What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? Also did ISO ever update 10589 to fix the errors/omissions in the 1st edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 from July 92 and / or other errors)? TIA Talmon _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 08:32:02 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07833 for ; Wed, 2 May 2001 08:32:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA18402; Wed, 2 May 2001 06:09:11 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA18390 for ; Wed, 2 May 2001 06:08:27 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42CLhb11770 for ; Wed, 2 May 2001 05:21:43 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp25.cisco.com [144.254.108.92]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA23298; Wed, 2 May 2001 13:25:55 +0100 (BST) Message-Id: <4.3.2.7.2.20010502131827.00b50d98@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Talmon_Reiss From: mike shand Subject: Re: [Isis-wg] Operation of P-toP links Cc: "IS-IS Mailing List (E-mail)" In-Reply-To: <2B15221907365C468941FDFC02C8776932391B@EXCHANGE.kerenix.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 May 2001 13:25:12 +0100 At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: >Hi > >I have some questions regarding the operation of P-to-P links in IS-IS: >After the establishment of a P-to-P adjacency what exactly happens wrt to >LSP transmission ? >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? Its an optimization (only). Receipt of a CSNP from the neighbor specifying which LSPs the neighbor has allows you to clear SRMflags for those LSPs and hence avoid transmitting them. Clearly if the link is to a neighbor which has just come up (as opposed to a link just coming up to a neighbor which has a full LSP database), then there will be no optimization. But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still result in correct synchronization. Its just that it may require the unnecessary transmission of some or all the LSPs. >What is the purpose of the partialSNPInterval timer? When is it used? The idea is to batch up the acknowledgements. The only requirement is that the ack is received before the re-transmit happens. SO by delaying the sending of the PSNP it is likely that multiple LSPs can be acknowledged in the same PSNP. >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is NOT cleared until either a PSNP has been received or an LSP with equal or newer sequence number. >Also did ISO ever update 10589 to fix the errors/omissions in the 1st >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 >from July 92 and / or other errors)? There is a version 2 currently being progressed by ISO. Note DO NOT confuse this with an earlier V2 draft which was circulating a couple of years ago which contained MANY errors. >TIA >Talmon > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 09:21:50 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09707 for ; Wed, 2 May 2001 09:21:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA18684; Wed, 2 May 2001 07:00:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA18661 for ; Wed, 2 May 2001 06:59:22 -0700 (PDT) Received: from EXCHANGE.kerenix.com ([212.150.1.82]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42DCwb12896 for ; Wed, 2 May 2001 06:12:59 -0700 (PDT) X-JNPR-Received-From: outside Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <22WLZAJ7>; Wed, 2 May 2001 16:19:11 +0300 Message-ID: <2B15221907365C468941FDFC02C8776932391D@EXCHANGE.kerenix.com> From: Talmon_Reiss To: "IS-IS Mailing List (E-mail)" Subject: RE: [Isis-wg] Operation of P-toP links MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 May 2001 16:19:11 +0300 Hi again - thanks for replying So if I understand you correctly: On a P-to-P link, FIRST, a CSNP is sent, thus maybe saving the transmission of some LSPs from the neighbour. Then each sends his LSPs, which you acknowledge when the partialSNPInterval timer fires. Then basically this previous sentence is repeated when an IS receives new LSPs to propagate. Is my understanding correct? Another question: Say hypothetically, that a IS with a P-to-P adjacency "lost" an LSP from its database. Apart from waiting for a retransmission of this LSP from its neighbour (after maximumLSPGenerationInterval seconds), is there any other way to get this LSP sooner? Thanks Talmon -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 02, 2001 3:25 PM To: Talmon_Reiss Cc: IS-IS Mailing List (E-mail) Subject: Re: [Isis-wg] Operation of P-toP links At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: >Hi > >I have some questions regarding the operation of P-to-P links in IS-IS: >After the establishment of a P-to-P adjacency what exactly happens wrt to >LSP transmission ? >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? Its an optimization (only). Receipt of a CSNP from the neighbor specifying which LSPs the neighbor has allows you to clear SRMflags for those LSPs and hence avoid transmitting them. Clearly if the link is to a neighbor which has just come up (as opposed to a link just coming up to a neighbor which has a full LSP database), then there will be no optimization. But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still result in correct synchronization. Its just that it may require the unnecessary transmission of some or all the LSPs. >What is the purpose of the partialSNPInterval timer? When is it used? The idea is to batch up the acknowledgements. The only requirement is that the ack is received before the re-transmit happens. SO by delaying the sending of the PSNP it is likely that multiple LSPs can be acknowledged in the same PSNP. >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is NOT cleared until either a PSNP has been received or an LSP with equal or newer sequence number. >Also did ISO ever update 10589 to fix the errors/omissions in the 1st >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 >from July 92 and / or other errors)? There is a version 2 currently being progressed by ISO. Note DO NOT confuse this with an earlier V2 draft which was circulating a couple of years ago which contained MANY errors. >TIA >Talmon > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 09:43:23 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10655 for ; Wed, 2 May 2001 09:43:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA18824; Wed, 2 May 2001 07:20:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA18804 for ; Wed, 2 May 2001 07:19:21 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42DX0b13411 for ; Wed, 2 May 2001 06:33:00 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp25.cisco.com [144.254.108.92]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA29452; Wed, 2 May 2001 14:33:54 +0100 (BST) Message-Id: <4.3.2.7.2.20010502142905.03490060@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Talmon_Reiss From: mike shand Subject: RE: [Isis-wg] Operation of P-toP links Cc: "IS-IS Mailing List (E-mail)" In-Reply-To: <2B15221907365C468941FDFC02C8776932391D@EXCHANGE.kerenix.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 May 2001 14:33:09 +0100 At 16:19 02/05/2001 +0300, Talmon_Reiss wrote: >Hi again - thanks for replying > >So if I understand you correctly: >On a P-to-P link, FIRST, a CSNP is sent, thus maybe saving the transmission >of some LSPs from the neighbour. Then each sends his LSPs, which you >acknowledge when the partialSNPInterval timer fires. Then basically this >previous sentence is repeated when an IS receives new LSPs to propagate. Is >my understanding correct? Yes, if I understand you correctly. >Another question: >Say hypothetically, that a IS with a P-to-P adjacency "lost" an LSP from its >database. Apart from waiting for a retransmission of this LSP from its >neighbour (after maximumLSPGenerationInterval seconds), is there any other >way to get this LSP sooner? Well, it better hadn't arbitrarily loose LSPs!!! If it detects that an LSP it holds is corrupt (bad checksum in memory), then it can treat it as expired and hence get a new one. Alternatively if it KNOWS that it has "lost" the LSP it could adopt various strategies to try to get it back, but none of this is covered by the normal protocol. As I said, once a router has acknowledged an LSP it is its responsibility to preserve it in its memory. If it doesn't it should probably crash! Mike >Thanks >Talmon > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Wednesday, May 02, 2001 3:25 PM >To: Talmon_Reiss >Cc: IS-IS Mailing List (E-mail) >Subject: Re: [Isis-wg] Operation of P-toP links > > >At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: > >Hi > > > >I have some questions regarding the operation of P-to-P links in IS-IS: > >After the establishment of a P-to-P adjacency what exactly happens wrt to > >LSP transmission ? > >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? > >Its an optimization (only). Receipt of a CSNP from the neighbor specifying >which LSPs the neighbor has allows you to clear SRMflags for those LSPs and >hence avoid transmitting them. Clearly if the link is to a neighbor which >has just come up (as opposed to a link just coming up to a neighbor which >has a full LSP database), then there will be no optimization. > >But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still >result in correct synchronization. Its just that it may require the >unnecessary transmission of some or all the LSPs. > > >What is the purpose of the partialSNPInterval timer? When is it used? > >The idea is to batch up the acknowledgements. The only requirement is that >the ack is received before the re-transmit happens. SO by delaying the >sending of the PSNP it is likely that multiple LSPs can be acknowledged in >the same PSNP. > > >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? > >You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is >NOT cleared until either a PSNP has been received or an LSP with equal or >newer sequence number. > > > >Also did ISO ever update 10589 to fix the errors/omissions in the 1st > >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 > >from July 92 and / or other errors)? > >There is a version 2 currently being progressed by ISO. Note DO NOT confuse >this with an earlier V2 draft which was circulating a couple of years ago >which contained MANY errors. > > >TIA > >Talmon > > > > > > > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 13:40:03 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18195 for ; Wed, 2 May 2001 13:40:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA19843; Wed, 2 May 2001 11:18:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA19831 for ; Wed, 2 May 2001 11:17:39 -0700 (PDT) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42HVHb23673 for ; Wed, 2 May 2001 10:31:17 -0700 (PDT) X-JNPR-Received-From: outside Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 10:35:26 -0700 Message-ID: From: Neal Castagnoli To: "'mike shand'" , Talmon_Reiss Cc: "IS-IS Mailing List (E-mail)" Subject: RE: [Isis-wg] Operation of P-toP links MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 May 2001 10:35:25 -0700 > If it detects that an LSP it holds is corrupt (bad checksum > in memory), > then it can treat it as expired and hence get a new one. Treating corrupt LSPs as if they had expired causes a network wide purge of them. I could imagine a faulty router (maybe one with bad memory or bad software) frequently purging many LSPs and so cause network wide disruption. One way to "safely" recover is to reacquire the LSP database. You need a mechanism to cause the routers on the other side of WAN links to reinitialize them, and so cause the LSP database to be synchronized again. (This mechanism does not exist in 10589). We added a state machine to the WAN hello processing that allowed one side to notify the other that it was reinitializing the link, in NLSP, an ISIS knock-off. Among other things, this allowed NLSP to recover from corrupt LSPs. Recovering worked fine in the lab. After corrupting an LSP by hand in the database, the router would find the bad LSP during periodic LSP database verification. The router then released the entire contents of the database and reinitialized all the WAN links, thereby causing the LSPs to be reacquired. However, while it seems like a great idea to recover from corrupt LSPs, how does the router know the extent of the damage? It could be that other data structures are now in an inconsistent state, some of which could cause network wide disruption. This is why the (simple) idea of "crashing the router" makes a lot of sense. It can help to isolate the problem to a single node in the network (of course, it's best to prevent as many of these problems as practical in the first place!). > As I said, once a router has acknowledged an LSP it is its > responsibility > to preserve it in its memory. If it doesn't it should probably crash! > > Mike --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 14:59:33 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20147 for ; Wed, 2 May 2001 14:59:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA20219; Wed, 2 May 2001 12:38:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA20207 for ; Wed, 2 May 2001 12:37:50 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42IpRb27970 for ; Wed, 2 May 2001 11:51:27 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 20A2F26BD04; Wed, 2 May 2001 11:55:50 -0700 (PDT) Message-ID: <3AF054FA.55665265@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Neal Castagnoli Cc: "'mike shand'" , Talmon_Reiss , "IS-IS Mailing List (E-mail)" Subject: Re: [Isis-wg] Operation of P-toP links References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 May 2001 11:42:29 -0700 Content-Transfer-Encoding: 7bit Neal Castagnoli wrote: > > If it detects that an LSP it holds is corrupt (bad checksum > > in memory), > > then it can treat it as expired and hence get a new one. > > Treating corrupt LSPs as if they had expired causes a network wide purge of > them. I could imagine a faulty router (maybe one with bad memory or bad > software) frequently purging many LSPs and so cause network wide disruption. any decent implementation does only flush its own LSPs these days. Flushing other people LSPs has proven to be a bad idea. > We added a state machine to the WAN hello processing that allowed one side > to notify the other that it was reinitializing the link, in NLSP, an ISIS > knock-off. Among other things, this allowed NLSP to recover from corrupt > LSPs. > > Recovering worked fine in the lab. After corrupting an LSP by hand in the > database, the router would find the bad LSP during periodic LSP database > verification. The router then released the entire contents of the database > and reinitialized all the WAN links, thereby causing the LSPs to be > reacquired. even simpler solutions to the problem exist given some cooperation from your neighbor -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 17:54:26 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24647 for ; Wed, 2 May 2001 17:54:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA20956; Wed, 2 May 2001 15:33:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA20944 for ; Wed, 2 May 2001 15:32:33 -0700 (PDT) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42Lk9b36040 for ; Wed, 2 May 2001 14:46:09 -0700 (PDT) X-JNPR-Received-From: outside Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 14:50:32 -0700 Message-ID: From: Neal Castagnoli To: "'Tony Przygienda'" , Neal Castagnoli Cc: "'mike shand'" , Talmon_Reiss , "IS-IS Mailing List (E-mail)" Subject: RE: [Isis-wg] Operation of P-toP links MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 May 2001 14:50:23 -0700 > any decent implementation does only flush its own LSPs these > days. Flushing > other people LSPs has proven to be a bad idea. Right. In NLSP we eliminated the "bad checksum purge" when receiving corrupted LSPs, because a corrupting link (or misbehaving router on the other end of the link) could bring down a network. We discarded the bad ones, and alerted the administrator. The other instance of a network wide purge is receipt of an LSP that has the same "newness" (same sequence number, same lspid, both non-zero lifetime), but different checksums. In this case, we included checksum as a part of the "newer" calculation. LSPs with higher checksums were "newer." This prevented routers from purging others LSPs, and in the case of two routers battling over a system ID, it allowed the LSPs to flow back and forth between the battling routers (both routers complain). Is this being done with ISIS implementations? If so, it seems all routers need to have the same algorithm (what is it?). If not, what is being done to prevent the purge? >> > even simpler solutions to the problem exist given some > cooperation from your > neighbor > Do you know what the simpler solutions are? Care to describe them? (which begs the question of whether it is even right to try to recover!). > -- tony > --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 2 18:49:02 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25670 for ; Wed, 2 May 2001 18:49:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA21231; Wed, 2 May 2001 16:29:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA21219 for ; Wed, 2 May 2001 16:28:03 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f42MfJb38565 for ; Wed, 2 May 2001 15:41:19 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 7472E26BD1D; Wed, 2 May 2001 15:45:32 -0700 (PDT) Message-ID: <3AF08ACD.8DD72EE9@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Neal Castagnoli Cc: "'mike shand'" , Talmon_Reiss , "IS-IS Mailing List (E-mail)" Subject: Re: [Isis-wg] Operation of P-toP links References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 May 2001 15:32:11 -0700 Content-Transfer-Encoding: 7bit Neal Castagnoli wrote: > >> > > even simpler solutions to the problem exist given some > > cooperation from your > > neighbor > > > > Do you know what the simpler solutions are? Care to describe them? > > (which begs the question of whether it is even right to try to recover!). think sending SNPs when the spec doesn't call for it. Most implementation will do the right thing then. Whether it is right to recover depends on many things, one of them your marketing departement and overall architecture of the box ;-) 'nuff said -=-= tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 3 03:24:32 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16848 for ; Thu, 3 May 2001 03:24:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA23249; Thu, 3 May 2001 01:04:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA23237 for ; Thu, 3 May 2001 01:03:37 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f437H9b50960 for ; Thu, 3 May 2001 00:17:09 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp25.cisco.com [144.254.108.92]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA15394; Thu, 3 May 2001 08:21:23 +0100 (BST) Message-Id: <4.3.2.7.2.20010503080613.03471fb0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Neal Castagnoli From: mike shand Subject: RE: [Isis-wg] Operation of P-toP links Cc: "'Tony Przygienda'" , Neal Castagnoli , Talmon_Reiss , "IS-IS Mailing List (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 03 May 2001 08:20:21 +0100 At 14:50 02/05/2001 -0700, Neal Castagnoli wrote: > > any decent implementation does only flush its own LSPs these > > days. Flushing > > other people LSPs has proven to be a bad idea. Absolutely. I wasn't really advocating purging the bad checksum in memory case. My main concern was to emphasis that you shouldn't arbitrarily loose LSPs! >Right. In NLSP we eliminated the "bad checksum purge" when receiving >corrupted LSPs, because a corrupting link (or misbehaving router on the >other end of the link) could bring down a network. We discarded the bad >ones, and alerted the administrator. This is exactly what IS-IS does now. (There's a TC on ISO/IEC 10589 which says this). >The other instance of a network wide purge is receipt of an LSP that has the >same "newness" (same sequence number, same lspid, both non-zero lifetime), >but different checksums. In this case, we included checksum as a part of >the "newer" calculation. LSPs with higher checksums were "newer." This >prevented routers from purging others LSPs, and in the case of two routers >battling over a system ID, it allowed the LSPs to flow back and forth >between the battling routers (both routers complain). > >Is this being done with ISIS implementations? If so, it seems all routers >need to have the same algorithm (what is it?). I know of implementations which do this, but there is nothing which says which is the "right" way to do it (higher or lower checksum). As you say it is critical that all implementations choose the same algorithm. (Well, in fact it is safe for this to co-exist with the "standard" purging). But I'm not sure that this issue is particularly important (as opposed to the bad checksum in a received LSP, which is important, as we have real world evidence to show ) > If not, what is being done >to prevent the purge? > > >> > > even simpler solutions to the problem exist given some > > cooperation from your > > neighbor > > > >Do you know what the simpler solutions are? Care to describe them? Well, something along the lines of draft-shand-isis-restart-00.txt springs to mind! But as Tony says, you can do interesting things with SNPs. >(which begs the question of whether it is even right to try to recover!). > > > -- tony > > > > --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 3 11:59:38 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28231 for ; Thu, 3 May 2001 11:59:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA25446; Thu, 3 May 2001 09:35:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA25431 for ; Thu, 3 May 2001 09:34:20 -0700 (PDT) Received: from EXCHANGE.kerenix.com ([212.150.1.82]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f43Flmb64019 for ; Thu, 3 May 2001 08:47:48 -0700 (PDT) X-JNPR-Received-From: outside Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <22WLZCCF>; Thu, 3 May 2001 18:54:04 +0300 Message-ID: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> From: Talmon_Reiss To: "IS-IS Mailing List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Isis-wg] Receiving CSNPs in IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 3 May 2001 18:53:54 +0300 Hi If an IS receives an CSNP and there are LESS LSPs listed in it than it has in its own database, is this IS required to send the missing LSPs back on the same circuit? If so, according to what timer? Or is it immediate? Talmon _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 3 12:38:46 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29531 for ; Thu, 3 May 2001 12:38:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25662; Thu, 3 May 2001 10:13:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25650 for ; Thu, 3 May 2001 10:12:44 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f43GQCb65842 for ; Thu, 3 May 2001 09:26:13 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-161-44-19-46.cisco.com [161.44.19.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA00092; Thu, 3 May 2001 09:30:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20010503112938.03cbe008@ce-nfs-1.cisco.com> X-Sender: mbartell@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Talmon_Reiss From: Micah Bartell Subject: Re: [Isis-wg] Receiving CSNPs in IS-IS Cc: "IS-IS Mailing List (E-mail)" In-Reply-To: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 03 May 2001 11:30:30 -0500 You would set the SRM flags for those LSPs that are missing from the CSNP. The flooding would be when your flooding routine goes through and floods the LSPs with the SRMflag set. /mpb At 18:53 05/03/2001 +0300, Talmon_Reiss wrote: >Hi > >If an IS receives an CSNP and there are LESS LSPs listed in it than it has >in its own database, is this IS required to send the missing LSPs back on >the same circuit? If so, according to what timer? Or is it immediate? > >Talmon > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 3 12:40:54 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29634 for ; Thu, 3 May 2001 12:40:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25706; Thu, 3 May 2001 10:18:06 -0700 (PDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25694 for ; Thu, 3 May 2001 10:17:55 -0700 (PDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA14360; Thu, 3 May 2001 17:19:46 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA11624; Thu, 3 May 2001 18:29:16 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id SAA03132; Thu, 3 May 2001 18:35:25 +0200 (MET DST) Received: from reaumur.dinsunnet (reaumur [188.9.33.51]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id SAA25120; Thu, 3 May 2001 18:35:32 +0200 (MET DST) Received: from ms.alcatel.fr by reaumur.dinsunnet (SMI-8.6/SMI-SVR4) id SAA22075; Thu, 3 May 2001 18:30:31 +0200 Message-ID: <3AF187A7.FBE10F51@ms.alcatel.fr> From: Bruno Mongazon X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Talmon_Reiss , "isis-wg@spider.juniper.net" Subject: Re: [Isis-wg] Receiving CSNPs in IS-IS References: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 03 May 2001 18:30:31 +0200 Content-Transfer-Encoding: 7bit Talmon_Reiss wrote: > > Hi > > If an IS receives an CSNP and there are LESS LSPs listed in it than it has > in its own database, is this IS required to send the missing LSPs back on > the same circuit? If so, according to what timer? Or is it immediate? > > Talmon > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg Hi Talmon, I think it works as follows: A CSNP contains the START LSP ID and END LSP ID fields in addition to LSP entries. When an IS receives a CSNP it should scan its database within the range [START LSP ID, END LSP ID]. If no LSP entry is found in the CSNP for an LSP ID in that range, the IS should send the missing LSP back to the transmitter. My understanding is that the transmission of missing LSPs is immediate. My 2 cents. Bruno. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 4 03:05:15 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06067 for ; Fri, 4 May 2001 03:05:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA29111; Fri, 4 May 2001 00:45:06 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA29096 for ; Fri, 4 May 2001 00:44:58 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp25.cisco.com [144.254.108.92]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA17245; Fri, 4 May 2001 08:02:39 +0100 (BST) Message-Id: <4.3.2.7.2.20010504075845.019733f8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Bruno Mongazon From: mike shand Subject: Re: [Isis-wg] Receiving CSNPs in IS-IS Cc: Talmon_Reiss , "isis-wg@spider.juniper.net" In-Reply-To: <3AF187A7.FBE10F51@ms.alcatel.fr> References: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 04 May 2001 08:01:04 +0100 At 18:30 03/05/2001 +0200, Bruno Mongazon wrote: >Talmon_Reiss wrote: > > > > Hi > > > > If an IS receives an CSNP and there are LESS LSPs listed in it than it has > > in its own database, is this IS required to send the missing LSPs back on > > the same circuit? If so, according to what timer? Or is it immediate? > > > > Talmon > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > >Hi Talmon, > >I think it works as follows: > >A CSNP contains the START LSP ID and END LSP ID fields in addition to >LSP entries. >When an IS receives a CSNP it should scan its database within the range >[START LSP ID, END LSP ID]. If no LSP entry is found in the CSNP for an >LSP ID in that range, the IS should send the missing LSP back to the >transmitter. > >My understanding is that the transmission of missing LSPs is immediate. Mihah's description is slightly more accurate. You set SRMflags immediately, but the actual transmission takes place according to the usual transmission rules, including pacing and randomization where appropriate. In particular, if its a LAN and you hear the LSP in question transmitted by someone else before you have actually transmitted it, this would cause your SRMflag for that LSP to be cleared, so you wouldn't transmit it. Mike >My 2 cents. >Bruno. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 7 02:43:40 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04060 for ; Mon, 7 May 2001 02:43:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA79040; Mon, 7 May 2001 00:22:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA08901 for ; Mon, 30 Apr 2001 16:27:01 -0700 (PDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3UMehb51585 for ; Mon, 30 Apr 2001 15:40:43 -0700 (PDT) X-JNPR-Received-From: outside Received: from ieee.org (dungbeetle.antd.nist.gov [129.6.55.94]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA06036; Mon, 30 Apr 2001 18:44:58 -0400 (EDT) Message-ID: <3AEDEAE4.115750CB@ieee.org> From: Doug Montgomery Reply-To: dougm@ieee.org Organization: UMAC T-Ball Pirates X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: isis-wg@juniper.net, sivaa@indiatimes.com Subject: Re: [Isis-wg] downstream paths? References: <200104301938.PAA11826@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 18:44:52 -0400 Content-Transfer-Encoding: 7bit Radia, Of course Dave Oran could do a better job of providing the history, but you have the basic idea. Run Dijkstra routed at each of your immediate neighbors and store forwarding adjacencies for any of them that are closer to the destination than yourself. Provides very aggressive load splitting. A researcher from Denmark (? I can see the fellow's face, his name escapes me) proposed this in the early days of ISO standardization. The rationale at the time involved scenarios in which one was highly BW constrained and needed to get every drop of load splitting possible. I don't think many people other than the author saw the burning need, but on the other hand, after some analysis, it seemed well specified and workable and was added as a second algorithm. I have never seen an implementation of it. dougm Radia Perlman - Boston Center for Networking wrote: > > OK. Reading Jeff Parker's reply I now understand, but perhaps > it's worth having a 2nd person explain it. > > I didn't remember this from IS-IS at all (I assume > it got put in by ISO and wasn't in the original DECnet > Phase V routing algorithm), but apparently (based on > the section quoted by Jeff) you're > allowed to forward a packet destined to D to neighbor N even if > N isn't on a minimal path from you to D, but instead neighbor N > is closer to D than you are. In other words, you have a path through > neighbor N1 to D that is of cost 50, and that's your best path. > Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > If you forward through N your path will be 53, clearly worse than > your path through N1, but since N is closer to D than you (N is > 48 away, you're 50 away), you're allowed to forward to N. > > A neighbor closer to D than you is "downstream". So N (as well as N1) > would be downstream. > > The normal Dijkstra calculation wouldn't tell you all neighbors closer > to D than you. The only way to get this is to calculate Dijkstra > from the point of view of each neighbor. That's why, if you have k > neighbors, you'd have to calculate Dijkstra from your own point of > view, plus from the point of view of each neighbor (to find out, for > each destination, which of your neighbors is closer to the destination > than you are). > > And with multiple metrics, you'd have to multiply the number of Dijkstra > calculations by the number of metrics (I never did like the multiple > metric thing, especially the way ISO specified it...that you leave out > links that don't advertise that metric so you're calculating an "optimal" > path based on a subset of the links!). > > So that explains why the section you quoted says if there are 4 > metrics, and you want to "calculate downstream paths) i.e., find out > which neighbors are closer than you for each destination), you > "would execute the algorithm 4 * (number of neighbours +1) times" > > I always thought the multiple metrics were not worth the extra > calculation and configuration (and were actually quite dangerous > given how ISO specified it since it's very nonintuitive why you > might get really horrible routes if you use any metric that isn't > universally supported on every link). I'd think this "calculating > downstream paths" would also not be worth the extra computation > and storage. Does any IS-IS implementation bother with this > "downstream paths" thing? > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- +-----------------------------------------------------------------------------+ | Doug Montgomery Manager, Internetworking Technologies Group | | National Institute of Standards and Technology Email: dougm@nist.gov | | Building 820, Room 457 Voice: +1-301-975-3630 | | 820 West Diamond Avenue Fax: +1-301-590-0932 | | Gaithersburg, MD 20899 USA WWW: http://www.antd.nist.gov/itg/ | +-----------------------------------------------------------------------------+ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 9 08:32:19 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04812 for ; Wed, 9 May 2001 08:32:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA91912; Wed, 9 May 2001 06:12:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA91900 for ; Wed, 9 May 2001 06:11:15 -0700 (PDT) Received: from EXCHANGE.kerenix.com ([212.150.1.82]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f49CNdb53246 for ; Wed, 9 May 2001 05:23:44 -0700 (PDT) X-JNPR-Received-From: outside Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <22WLZJA0>; Wed, 9 May 2001 15:30:10 +0300 Message-ID: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.com> From: Talmon_Reiss To: "IS-IS Mailing List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Isis-wg] Adjacencies and LSP Numbers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 May 2001 15:30:09 +0300 Hi In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number." As I understood it, the LSP Number was supposd to be used when a LS PDU was too large to fit in a single LSP (the LSP Number 0 then has a special significance wrt to the DB overload bit etc). Could someone please clarify this concept of the link between an an adjacency and a LSP Number? Thanks Talmon _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 9 08:49:57 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05172 for ; Wed, 9 May 2001 08:49:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA92036; Wed, 9 May 2001 06:31:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA92024 for ; Wed, 9 May 2001 06:30:34 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f49Ch2b53719 for ; Wed, 9 May 2001 05:43:02 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp25.cisco.com [144.254.108.92]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA26865; Wed, 9 May 2001 13:47:33 +0100 (BST) Message-Id: <4.3.2.7.2.20010509134442.01e571b8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Talmon_Reiss From: mike shand Subject: Re: [Isis-wg] Adjacencies and LSP Numbers Cc: "IS-IS Mailing List (E-mail)" In-Reply-To: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 May 2001 13:47:46 +0100 At 15:30 09/05/2001 +0300, Talmon_Reiss wrote: >Hi > >In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to >a particular LSP Number, it is desirable that it not be moved to another LSP >Number." > >As I understood it, the LSP Number was supposd to be used when a LS PDU was >too large to fit in a single LSP (the LSP Number 0 then has a special >significance wrt to the DB overload bit etc). Correct >Could someone please clarify this concept of the link between an an >adjacency and a LSP Number? The point is that if you move an adjacency between one LSP and another, there are race conditions which can result in momentary loss of information. SO, for example if the new LSP without the adjacency propagates before the new LSP with the adjacency, then SPF may run and compute the topology without the link, then an SPF hold-down prevents SPF from being run again, so the new LSP doesn't get taken account of. So it is DESIRABLE not to arbitrarily move a link from one LSP to another. Mike >Thanks >Talmon > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 9 09:35:10 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06349 for ; Wed, 9 May 2001 09:35:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA92306; Wed, 9 May 2001 07:16:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA92294 for ; Wed, 9 May 2001 07:15:55 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f49DSNb54954 for ; Wed, 9 May 2001 06:28:23 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f49DVvm25494; Wed, 9 May 2001 09:31:57 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-115.cisco.com [64.102.83.115]) by dingdong.cisco.com (Mirapoint) with ESMTP id AFU44577; Wed, 9 May 2001 09:33:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010509092915.04ceb130@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Talmon_Reiss From: Jeff Learman Subject: Re: [Isis-wg] Adjacencies and LSP Numbers Cc: "IS-IS Mailing List (E-mail)" In-Reply-To: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 May 2001 09:32:57 -0400 At 08:30 AM 5/9/2001, Talmon_Reiss wrote: >Hi > >In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to >a particular LSP Number, it is desirable that it not be moved to another LSP >Number." > >As I understood it, the LSP Number was supposd to be used when a LS PDU was >too large to fit in a single LSP (the LSP Number 0 then has a special >significance wrt to the DB overload bit etc). You are correct. However, once an adjacency is assigned to an LSP fragment, it is "polite" to try to leave it in that same fragment. This avoids route flaps that can happen just because a link moved from one fragment to another, and a router receiving these LSPs gets the new LSP fragment without the link first and runs SPF -- only to receive the next new fragment where the link is up. >Could someone please clarify this concept of the link between an an >adjacency and a LSP Number? > >Thanks >Talmon > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 10 10:56:22 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29534 for ; Thu, 10 May 2001 10:56:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA98476; Thu, 10 May 2001 08:36:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA98464 for ; Thu, 10 May 2001 08:35:04 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4AElMb05628 for ; Thu, 10 May 2001 07:47:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07214 for ; Thu, 10 May 2001 10:52:05 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00934 for ; Thu, 10 May 2001 10:52:05 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 10:51:45 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5537DCA7@vie-msgusr-01.dc.fore.com> From: "Ju, Yu" To: "'isis-wg@juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] IP reachability information and IP interface address Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 May 2001 10:52:03 -0400 Hi, I have the following question regarding rfc1195.txt. 1). Suppose L1 A and L1 B are directly connected as the following. x and y are IP interface addresses on A and B respectively. -------- x y --------- | A |-----------------------------| B | --------- -------- x will be in the IP interface address field of A's L1 LSP. y will be in IP interface address field of B's L1 LSP. These information is enough for other IS in the area to calculate route to x and y. Then does A have to put y in the IP internal reachability information field of its L1 LSP? The same question for B. 2) Why L1 LSP can not have IP external reachability information? Thanks, Yu _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 10 11:23:17 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00420 for ; Thu, 10 May 2001 11:23:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA98651; Thu, 10 May 2001 09:03:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA98639 for ; Thu, 10 May 2001 09:02:18 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4AFEZb06789 for ; Thu, 10 May 2001 08:14:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4AFIBX05742; Thu, 10 May 2001 11:18:11 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-115.cisco.com [64.102.83.115]) by dingdong.cisco.com (Mirapoint) with ESMTP id AFY08766; Thu, 10 May 2001 11:19:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20010510111123.01a1ef20@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ju, Yu" From: Jeff Learman Subject: Re: [Isis-wg] IP reachability information and IP interface address Cc: "'isis-wg@juniper.net'" In-Reply-To: <39469E08BD83D411A3D900204840EC5537DCA7@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 May 2001 11:19:15 -0400 At 10:52 AM 5/10/2001, Ju, Yu wrote: >Hi, > >I have the following question regarding rfc1195.txt. > >1). Suppose L1 A and L1 B are directly connected as the following. x and y >are IP interface addresses on A and B respectively. > > > -------- x y --------- > | A |-----------------------------| B | > --------- -------- > > x will be in the IP interface address field of A's L1 LSP. y will be >in IP interface address field of B's L1 LSP. These information is enough for >other IS in the area to calculate route to x and y. Then does A have to put >y in the IP internal reachability information field of its L1 LSP? The same >question for B. This is enough information to calculate the routes ONLY if these routers are actually connected. There are too many situations where these routers might not actually be connected (e.g., switch failure). Routes must be known to be available by IIH handshake in order to use them for transit routing. >2) Why L1 LSP can not have IP external reachability information? IS-IS is a hierarchical system to reduce the amount of information that an L1 router needs to know to do its job. If the rules were changed to permit L1 routers to perform L2 functions (i.e., forwarding L2 traffic anywhere but to the nearest L2 router), this would obliterate the hierarchical distinction and would be a fairly radical change to IS-IS. >Thanks, > >Yu > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 10 11:30:22 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00620 for ; Thu, 10 May 2001 11:30:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA98716; Thu, 10 May 2001 09:10:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA98701 for ; Thu, 10 May 2001 09:09:42 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4AFLxb07100 for ; Thu, 10 May 2001 08:22:00 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11821; Thu, 10 May 2001 11:26:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12816; Thu, 10 May 2001 11:26:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 11:26:23 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5531DC8E@vie-msgusr-01.dc.fore.com> From: "Sunkad, Ravindra" To: "'Jeff Learman'" , "Ju, Yu" Cc: "'isis-wg@juniper.net'" Subject: RE: [Isis-wg] IP reachability information and IP interface addres s MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 May 2001 11:26:40 -0400 > >2) Why L1 LSP can not have IP external reachability information? > > IS-IS is a hierarchical system to reduce the amount of information > that an L1 router needs to know to do its job. If the rules were > changed to permit L1 routers to perform L2 functions (i.e., forwarding > L2 traffic anywhere but to the nearest L2 router), this would > obliterate the hierarchical distinction and would be a fairly > radical change to IS-IS. > First paragraph in section 2.2 of RFC-2966 removes this restriction. Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 14 22:43:10 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01173 for ; Mon, 14 May 2001 22:43:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA25683; Mon, 14 May 2001 20:22:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA25671 for ; Mon, 14 May 2001 20:21:17 -0700 (PDT) Received: from redd99.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4F2Wnb41598 for ; Mon, 14 May 2001 19:32:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd99.procket.com (8.9.3/8.9.3) with ESMTP id TAA21878; Mon, 14 May 2001 19:37:48 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B00967C.4AD71D4@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net CC: myeung@procket.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Optional Checksum in ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 May 2001 19:37:48 -0700 Content-Transfer-Encoding: 7bit Hi, What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. Thanks, - Derek _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 05:52:37 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19573 for ; Tue, 15 May 2001 05:52:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA27525; Tue, 15 May 2001 03:33:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA27513 for ; Tue, 15 May 2001 03:32:52 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4F9iKb50158 for ; Tue, 15 May 2001 02:44:21 -0700 (PDT) X-JNPR-Received-From: outside Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 15 May 2001 15:25:23 +0530 Received: from amudha (amudha.future.futsoft.com [192.168.5.7]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f4FHmf401868 for ; Tue, 15 May 2001 23:18:41 +0530 Reply-To: From: "Amudhavalli Narayanan" To: Message-Id: <000001c0dd25$502a6ce0$0705a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Regarding Area address option in non-pseudo LSPs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 15:26:28 +0530 X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id DAA27525 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA19573 Hi, In section 7.3.5 of ISIS standard it is staes that: The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. - In the Area Addresses option – the set of manualAreaAd-dresses for this Intermediate System. In section 9.7 it states that: For non-pseudonode LSPs this option (Area addresses) shall always be pre- sent in the LSP with LSP number zero, and shall never be present in an LSP with non-zero LSP number. This option shall never be present in pseudonode LSPs. Aren't these statements contradictory or is my understanding wrong? Can anyone please help me out? Thanks and Regards, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 10:10:55 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27932 for ; Tue, 15 May 2001 10:10:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28600; Tue, 15 May 2001 07:51:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28588 for ; Tue, 15 May 2001 07:50:25 -0700 (PDT) Received: from redcs4.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FE1rb56552 for ; Tue, 15 May 2001 07:01:53 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redcs4.procket.com (8.9.3/8.9.3) id HAA02691; Tue, 15 May 2001 07:06:48 -0700 From: Henk Smit Message-Id: <200105151406.HAA02691@redcs4.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Regarding Area address option in non-pseudo LSPs To: amudha@future.futsoft.com Cc: isis-wg@juniper.net In-Reply-To: <000001c0dd25$502a6ce0$0705a8c0@future.futsoft.com> from "Amudhavalli Narayanan" at May 15, 2001 03:26:28 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 07:06:48 -0700 (PDT) X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id HAA28600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27932 > In section 7.3.5 of ISIS standard it is staes that: > > The Level 1 Link State PDU not generated on behalf of a pseudonode "L1 LSP *not* generated on behalf of a pseudonode". So this is clearly about "non-pseudonode LSPs". > contains the following information in its variable length fields. > - In the Area Addresses option – the set of manualAreaAd-dresses > for this Intermediate System. Point made is "non-pseudonode LSPs can hold area-addresses" > In section 9.7 it states that: > For non-pseudonode LSPs this option (Area addresses) shall always be pre- > sent in the LSP with LSP number zero, and shall never be present in an LSP > with non-zero LSP number. Clearly about "non-pseudonode LSPs". Point made is "non-pseudonode LSPs can hold area-addresses" > This option shall never be present in pseudonode LSPs. Clearly about "pseudonode LSPs". Point made is "pseudonode LSPs can *not* hold area-addresses" > Aren't these statements contradictory or is my understanding wrong? Can > anyone please help me out? Mmmm, I see no contradiction ? henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 13:18:10 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03333 for ; Tue, 15 May 2001 13:18:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA29416; Tue, 15 May 2001 10:59:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA29404 for ; Tue, 15 May 2001 10:58:31 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4FH9wb65043 for ; Tue, 15 May 2001 10:09:58 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 16811 invoked from network); 15 May 2001 17:14:58 -0000 Received: from unknown (HELO commsense) ([216.27.158.30]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 May 2001 17:14:58 -0000 From: "Larmer" To: "Isis-Wg@Juniper. Net" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 13:16:28 -0400 Content-Transfer-Encoding: 7bit Hi, I was wondering if anyone knows why Cisco includes the neighbour's IP interface address (host address) for a Point-to-Point interface in its L2 LSP IP Internal Reachability Information TLV? Cheers, Ken Larmer CommSense Networks www.commsense.net _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 14:17:31 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04340 for ; Tue, 15 May 2001 14:17:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA29715; Tue, 15 May 2001 11:58:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA29703 for ; Tue, 15 May 2001 11:57:53 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FI9Fb68349 for ; Tue, 15 May 2001 11:09:15 -0700 (PDT) X-JNPR-Received-From: outside Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4FI7Ct07392; Tue, 15 May 2001 11:12:30 -0700 (PDT) Received: from cisco.com (ios-xdm1.cisco.com [171.69.26.46]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAV06005 (AUTH sluong); Tue, 15 May 2001 11:08:36 -0700 (PDT) Message-ID: <3B0170A4.CC899E69@cisco.com> From: Steven Luong X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Larmer CC: "Isis-Wg@Juniper. Net" Subject: Re: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 11:08:36 -0700 Content-Transfer-Encoding: 7bit That is called redistribution, from level-1 into level-2, which is automatic. Larmer wrote: > Hi, > > I was wondering if anyone knows why Cisco includes > the neighbour's IP interface address (host address) for a > Point-to-Point interface in its L2 LSP IP Internal > Reachability Information TLV? > > Cheers, > > Ken Larmer > CommSense Networks > www.commsense.net > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Steven Luong _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 14:27:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04660 for ; Tue, 15 May 2001 14:27:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA29800; Tue, 15 May 2001 12:09:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA29788 for ; Tue, 15 May 2001 12:08:52 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4FIKIb69076 for ; Tue, 15 May 2001 11:20:18 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 45748 invoked from network); 15 May 2001 18:25:19 -0000 Received: from unknown (HELO commsense) ([216.27.158.30]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 May 2001 18:25:19 -0000 From: "Larmer" To: "Steven Luong" Cc: "Isis-Wg@Juniper. Net" Subject: RE: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3B0170A4.CC899E69@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 14:26:49 -0400 Content-Transfer-Encoding: 7bit Hi, Thanks Steve, though I don't understand? This IP (host) address does not show up in Level-1 LSPs? Only in L2 LSPs. Besides, we are advertising the IP subnet already, why do we need to advertise the host specific address? And why only on Point-to-Point interfaces? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Steven Luong Sent: Tuesday, May 15, 2001 2:09 PM To: Larmer Cc: Isis-Wg@Juniper. Net Subject: Re: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV That is called redistribution, from level-1 into level-2, which is automatic. Larmer wrote: > Hi, > > I was wondering if anyone knows why Cisco includes > the neighbour's IP interface address (host address) for a > Point-to-Point interface in its L2 LSP IP Internal > Reachability Information TLV? > > Cheers, > > Ken Larmer > CommSense Networks > www.commsense.net > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Steven Luong _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 19:11:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09230 for ; Tue, 15 May 2001 19:11:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA30978; Tue, 15 May 2001 16:31:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA30966 for ; Tue, 15 May 2001 16:30:41 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FMg5b80984 for ; Tue, 15 May 2001 15:42:05 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA01901 for ; Tue, 15 May 2001 18:47:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25785 for ; Tue, 15 May 2001 18:47:07 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 May 2001 18:46:38 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> From: "Sunkad, Ravindra" To: "Isis-Wg@Juniper. Net" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] Three-way Handshake question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 18:47:04 -0400 Hi, I have a question related to the Three-Way handshake operation. In the "Point-to-Point Adjacency State" TLV definition of draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. However, I have noticed that some implementations have only the "Adjacency State" included in this TLV. i.e. "Extended Local Circuit ID" is not included. What is the expected behavior on receipt of such a IIH PDU? Thanks, Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 19:17:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09350 for ; Tue, 15 May 2001 19:17:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA31130; Tue, 15 May 2001 16:58:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA31115 for ; Tue, 15 May 2001 16:56:07 -0700 (PDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FN7Vb82025 for ; Tue, 15 May 2001 16:07:31 -0700 (PDT) X-JNPR-Received-From: outside Received: from premalpc by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA02349; Tue, 15 May 2001 16:12:21 -0700 (PDT) Reply-To: From: "Premal Ashar" To: "Sunkad, Ravindra" , "Isis-Wg@Juniper. Net" Subject: RE: [Isis-wg] Three-way Handshake question Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 15:03:02 -0700 Content-Transfer-Encoding: 7bit Hi Ravi, I believe that draft-ietf-isis-3way-02 did not have the "Extended Local Circuit ID" support while draft-ietf-isis-3way-03 does have. Hence the implementations based on 02 will not have "Extended Local Circuit ID" support. draft-ietf-isis-3way-03 is backward compatible with draft-ietf-isis-3way-02, so the behavior should not matter. -- Premal Ashar Member of Technical Staff Email: premal@riverstonenet.com Riverstone Networks Tel: (408)878-6515 5200 Great America Parkway FAX: (408)878-6501 Santa Clara, CA 95054 http://www.riverstonenet.com -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Sunkad, Ravindra Sent: Tuesday, May 15, 2001 3:47 PM To: Isis-Wg@Juniper. Net Subject: [Isis-wg] Three-way Handshake question Hi, I have a question related to the Three-Way handshake operation. In the "Point-to-Point Adjacency State" TLV definition of draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. However, I have noticed that some implementations have only the "Adjacency State" included in this TLV. i.e. "Extended Local Circuit ID" is not included. What is the expected behavior on receipt of such a IIH PDU? Thanks, Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 19:28:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09584 for ; Tue, 15 May 2001 19:28:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31213; Tue, 15 May 2001 17:09:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31196 for ; Tue, 15 May 2001 17:08:14 -0700 (PDT) Received: from redcs4.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FNJQb82458 for ; Tue, 15 May 2001 16:19:26 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redcs4.procket.com (8.9.3/8.9.3) id QAA01998; Tue, 15 May 2001 16:24:18 -0700 From: Henk Smit Message-Id: <200105152324.QAA01998@redcs4.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Three-way Handshake question To: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Cc: isis-wg@juniper.net (Isis-Wg@Juniper. Net) In-Reply-To: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> from "Sunkad, Ravindra" at May 15, 2001 06:47:04 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 16:24:18 -0700 (PDT) Content-Transfer-Encoding: 7bit > > Hi, > > I have a question related to the Three-Way handshake operation. > > In the "Point-to-Point Adjacency State" TLV definition of > draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. > However, I have noticed that some implementations have only the "Adjacency > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > included. > > What is the expected behavior on receipt of such a IIH PDU? Be strict in what you send, be liberal in what you accept. The first version of the 3-way handshake used to have only the "Adjacency State" included. Many years after this had been implemented, the need for more information in the TLV arose. There are still a zillion routers out there that only send and understand the first byte of the TLV. The dominant implementation of those days luckily will ignore any extra bytes in the TLV. So IMHO if you know about this, you should build your implementation in such a way that it will be able to interoperate with these older boxes. Your customers will appreciate it. hope this helps, henk. > Thanks, > Ravi > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 19:53:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09944 for ; Tue, 15 May 2001 19:53:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31438; Tue, 15 May 2001 17:35:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31423 for ; Tue, 15 May 2001 17:34:58 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4FNkLb83652 for ; Tue, 15 May 2001 16:46:21 -0700 (PDT) X-JNPR-Received-From: outside Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id TAA22158; Tue, 15 May 2001 19:51:17 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Tue, 15 May 2001 19:51:20 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTDD0CW9; Tue, 15 May 2001 19:51:20 -0400 Received: from nortelnetworks.com (RSALUJA2 [47.16.4.179]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JPBDLDJ0; Tue, 15 May 2001 19:51:19 -0400 Message-ID: <3B01C0C4.F7567185@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: premal CC: "Sunkad, Ravindra" , "Isis-Wg@Juniper. Net" Subject: Re: [Isis-wg] Three-way Handshake question References: Content-Type: multipart/mixed; boundary="------------855F676E1993D3F3671E4929" X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 19:50:28 -0400 This is a multi-part message in MIME format. --------------855F676E1993D3F3671E4929 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: quoted-printable Ravi, Premal, Extended Local circuit Id has been there in all versions of 3way handshak= e draft. The draft is backward compatible with=A0 the implementation contai= ning only "adjacency state" in the TLV. Thanks, Rajesh =A0 =A0 Premal Ashar wrote: > Hi Ravi, > > I believe that draft-ietf-isis-3way-02 did not have the "Extended Local= > Circuit ID" support while draft-ietf-isis-3way-03 does have. Hence the > implementations based on 02 will not have "Extended Local Circuit ID" > support. draft-ietf-isis-3way-03 is backward compatible with > draft-ietf-isis-3way-02, so the behavior should not matter. > > -- > Premal Ashar > Member of Technical Staff=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ema= il: premal@riverstonenet.com > Riverstone Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Tel: (408)878-6515 > 5200 Great America Parkway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: = (408)878-6501 > Santa Clara, CA 95054=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 http://www.riverstonenet.com > > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Sunkad, Ravindra > Sent: Tuesday, May 15, 2001 3:47 PM > To: Isis-Wg@Juniper. Net > Subject: [Isis-wg] Three-way Handshake question > > Hi, > > I have a question related to the Three-Way handshake operation. > > In the "Point-to-Point Adjacency State" TLV definition of > draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets= =2E > However, I have noticed that some implementations have only the "Adjace= ncy > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > included. > > What is the expected behavior on receipt of such a IIH PDU? > > Thanks, > Ravi > _______________________________________________ > Isis-wg mailing list=A0 -=A0 Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list=A0 -=A0 Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg --------------855F676E1993D3F3671E4929 Content-Type: text/x-vcard; charset=x-user-defined; name="rsaluja~vcf" Content-Description: Card for Saluja, Rajesh [BL60:424:EXCH] Content-Disposition: attachment; filename="rsaluja~vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Saluja;Rajesh tel;fax:978 288 4837 tel;work:978 288 7791 x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:rsaluja@baynetworks.com fn:Rajesh Saluja end:vcard --------------855F676E1993D3F3671E4929-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 15 20:05:41 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10053 for ; Tue, 15 May 2001 20:05:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31538; Tue, 15 May 2001 17:47:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA31526 for ; Tue, 15 May 2001 17:46:42 -0700 (PDT) Received: from yarilo.pluris.com (host200.pluris.com [208.227.9.200]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FNw6b84013 for ; Tue, 15 May 2001 16:58:06 -0700 (PDT) X-JNPR-Received-From: outside Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA25226; Tue, 15 May 2001 17:02:26 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <2ABFRD40>; Tue, 15 May 2001 17:02:26 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA055F95@avalon.pluris.com> From: Les Ginsberg To: "'Henk Smit'" , Ravindra.Sunkad@marconi.com Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Three-way Handshake question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 17:02:22 -0700 All very true. Which is why it would be "nice" if the current 3way draft were updated to indicate that the TLV has an acceptable form that includes only the adjacency state and that the len could be "1-17" rather than "5-17". Given that the old form of handshake is still in widespread use this is more than a historical issue. Les > > > > > > Hi, > > > > I have a question related to the Three-Way handshake operation. > > > > In the "Point-to-Point Adjacency State" TLV definition of > > draft-ietf-isis-3way-03, length is defined to be between 5 > to 17 octets. > > However, I have noticed that some implementations have only > the "Adjacency > > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > > included. > > > > What is the expected behavior on receipt of such a IIH PDU? > > Be strict in what you send, be liberal in what you accept. > > The first version of the 3-way handshake used to have only > the "Adjacency > State" included. Many years after this had been implemented, > the need for > more information in the TLV arose. There are still a zillion > routers out > there that only send and understand the first byte of the > TLV. The dominant > implementation of those days luckily will ignore any extra > bytes in the TLV. > > So IMHO if you know about this, you should build your > implementation in > such a way that it will be able to interoperate with these > older boxes. > Your customers will appreciate it. > > hope this helps, > > henk. > > > > Thanks, > > Ravi > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 16 02:24:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27880 for ; Wed, 16 May 2001 02:23:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA33095; Wed, 16 May 2001 00:05:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA33080 for ; Wed, 16 May 2001 00:04:49 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4G6GAb92557 for ; Tue, 15 May 2001 23:16:10 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.49.139]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GDF0052E0ATGJ@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Tue, 15 May 2001 23:20:55 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Optional Checksum in ISIS To: Derek Yeung Cc: isis-wg@juniper.net Message-id: <3B0218EF.A8739945@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3B00967C.4AD71D4@procket.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 23:06:39 -0700 Content-Transfer-Encoding: 7bit Derek Yeung wrote: > Hi, > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > Thanks, > - Derek > ________________________________ passed last call and was forwarded to ADs a nice while ago with couple other drafts. There was some serious feet-dragging there and change of ADs just happened as well. I hope to see the RFC out anytime soon ... If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 16 02:27:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28150 for ; Wed, 16 May 2001 02:27:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA33131; Wed, 16 May 2001 00:09:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA28998 for ; Tue, 15 May 2001 09:18:32 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4FFTxb59844 for ; Tue, 15 May 2001 08:29:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19995; Tue, 15 May 2001 08:34:54 -0700 (PDT) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA22318; Tue, 15 May 2001 11:34:54 -0400 (EDT) Message-Id: <200105151534.LAA22318@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Regarding Area address option in non-pseudo LSPs To: isis-wg@juniper.net, amudha@future.futsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: UtxQVD7zoRtM/NyRLY35Wg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by external.juniper.net id JAA28999 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 May 2001 11:34:54 -0400 (EDT) X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id AAA33131 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA28150 Amudha asked: Hi, In section 7.3.5 of ISIS standard it is staes that: The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. - In the Area Addresses option – the set of manualAreaAd-dresses for this Intermediate System. In section 9.7 it states that: For non-pseudonode LSPs this option (Area addresses) shall always be pre- sent in the LSP with LSP number zero, and shall never be present in an LSP with non-zero LSP number. This option shall never be present in pseudonode LSPs. Aren't these statements contradictory or is my understanding wrong? Can anyone please help me out? Thanks and Regards, Amudha Henk replied, and his reply was correct, but I think I can offer a more tutorial explanation. "Pseudonodes" are a way of making a LAN look like a node to the routing algorithm, which makes the database and computation scale better than the alternative, which would be considering all the nodes connected to the LAN to be fully connected, and each reporting links to all the others. So the DR "names" the LAN, and each node on that LAN just reports a single neighbor (that LAN, i.e., the pseudonode). The DR, in addition to the LSP it generates on behalf of itself (the "non-pseudonode LSP), generates an LSP on behalf of the LAN (the "pseudonode LSP"). Sending manual area addresses around in LSPs is a way to ensure that all the routers in the area agree on what the area addresses for that area are. All the routers need to find out what area addresses have been configured into other routers in that area. If area addresses were reported in ALL LSPs (pseudonode and non-pseudonode), then that would just be duplicative info, since the DR would report the same set in both its non-pseudonode LSP and its pseudonode LSP. So the spec says to ONLY report it in non-pseudonode LSPs. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 16 19:07:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20920 for ; Wed, 16 May 2001 19:07:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA37246; Wed, 16 May 2001 16:48:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA37234 for ; Wed, 16 May 2001 16:47:25 -0700 (PDT) Received: from redd99.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4GMwcb30336 for ; Wed, 16 May 2001 15:58:38 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd99.procket.com (8.9.3/8.9.3) with ESMTP id QAA27111; Wed, 16 May 2001 16:03:40 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B03074C.98CB85F3@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tony Przygienda CC: isis-wg@juniper.net Subject: Re: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 May 2001 16:03:40 -0700 Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > > Derek Yeung wrote: > > > Hi, > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > Thanks, > > - Derek > > ________________________________ > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > There was some serious feet-dragging there and change of ADs just happened > as well. I hope to see the RFC out anytime soon ... > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. Any big change between the 01 draft and the final RFC ? If there is no important change, my copy would be good enough. BTW, I have a few questions about the 01 draft. The draft said one cannot rely on authentication as checksum mechanism. Does the draft refer to simple cleartext authentication in particular or any authentication scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, in OSPF, checksum is not calculated when MD5 authentication is used. The only problem I see is that one cannot tell whether error is due to packet corruption or real authentication failure, but it is probably not a big deal. The draft also said that an implemenation that implements optional checksum MUST accept PDUs which do not contain optional checksum. Given that a checksumed PDU could be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? Thanks, - Derek > > thanks > > -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 16 20:34:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21782 for ; Wed, 16 May 2001 20:34:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA37682; Wed, 16 May 2001 18:16:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA37667 for ; Wed, 16 May 2001 18:15:28 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H0Qfb33447 for ; Wed, 16 May 2001 17:26:41 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 2B0FE26BD10; Wed, 16 May 2001 17:31:46 -0700 (PDT) Message-ID: <3B03187A.D475065E@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Derek Yeung Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 May 2001 17:17:26 -0700 Content-Transfer-Encoding: 7bit Derek Yeung wrote: > Tony Przygienda wrote: > > > > Derek Yeung wrote: > > > > > Hi, > > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > > > Thanks, > > > - Derek > > > ________________________________ > > > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > > There was some serious feet-dragging there and change of ADs just happened > > as well. I hope to see the RFC out anytime soon ... > > > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. > > Any big change between the 01 draft and the final RFC ? If there is no important > change, my copy would be good enough. don't remember what 01 was but the only change that pretty much ever came up was the issue of whehter you calculate csum first or authentication. Nischal caught that when implementing. > BTW, I have a few questions about the 01 draft. > > The draft said one cannot rely on authentication as checksum mechanism. > Does the draft refer to simple cleartext authentication in particular or any authentication > scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, > in OSPF, checksum is not calculated when MD5 authentication is used. The only problem > I see is that one cannot tell whether error is due to packet corruption or > real authentication failure, but it is probably not a big deal. well, source authentication should imply integrity in security so it's kind of true what you're saying. However, this clear text password is a glaring hole here (it's basically not authentication ;-) So having said that, we could add a sentence or so to the draft saying that if it's clear that authentication verifies integrity of the packet, checksum can be omitted. Read on ... > The draft also said that an implemenation that implements optional checksum MUST > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more important to not make the assumption that someone MUST put optional checksums on packets (equivalent to saying that you MUST NOT or MAY only accept packets without optional checksums). That would render piles of existing deployment problematic and lead to nasty effects when boxes are misconfigured. Also, that would introduce even more dependencies with the previous point you brought up since you'd have to say e.g. "must accept pdus which do not contain optional checksum if md5 is present". then of course think about the case where the checksum tlv got corrupted so it's not present anymore AND md5 got corrupted to deliver correct verification for that corrupted packet. Worst of all I think saying that "you must not accept packets without optional checksum when you expect it" would prevent in future boxes from being shipped with optional checksums enabled as default which I'd like to see ideally. All that doesn't end and has a 0.00001% of a chance to show up in real networks ;-) To summarize, I'd like to keep MD5 and checksums decoupled for simplicity reasons and only resolve the dependency which one's to be computed/verified first when received so I'd resist either change you brought up. - -tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 16 20:40:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21844 for ; Wed, 16 May 2001 20:40:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA37726; Wed, 16 May 2001 18:21:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA37551 for ; Wed, 16 May 2001 17:50:32 -0700 (PDT) Received: from gnat.inet.org ([63.108.254.91]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H01jb32686 for ; Wed, 16 May 2001 17:01:45 -0700 (PDT) X-JNPR-Received-From: outside Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 4F1E78266E; Wed, 16 May 2001 20:06:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20010516200305.00a1dec0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Derek Yeung From: RJ Atkinson Subject: Re: [Isis-wg] Optional Checksum in ISIS Cc: isis-wg@juniper.net In-Reply-To: <3B03074C.98CB85F3@procket.com> References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 May 2001 20:04:09 -0400 At 19:03 16/05/01, Derek Yeung wrote: >IMHO, MD5 authentication alone should be able to detect packet corruption. For example, in OSPF, checksum is not calculated >when MD5 authentication is used. Quite right on both counts. >The only problem I see is that one cannot tell whether error >is due to packet corruption or real authentication failure, >but it is probably not a big deal. Agree. Ran _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 03:32:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11690 for ; Thu, 17 May 2001 03:32:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA39428; Thu, 17 May 2001 01:14:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA39416 for ; Thu, 17 May 2001 01:13:18 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H7OSb42130 for ; Thu, 17 May 2001 00:24:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 17 May 2001 13:05:41 +0530 Received: from amudha (amudha.future.futsoft.com [192.168.5.7]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f4HFSt427297 for ; Thu, 17 May 2001 20:58:56 +0530 Reply-To: From: "Amudhavalli Narayanan" To: Message-Id: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Regarding manual area address Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 13:06:53 +0530 Content-Transfer-Encoding: 7bit Hi, Can some one help me in understanding the attached flag? Will it be set for this setup? R1 - L1L2 router in manually configured area a1 R2 - L1L2 router in manually configured areas a1, a2. Will R1 set the attached flag as it can reach a2 via R2? Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 04:06:34 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11937 for ; Thu, 17 May 2001 04:06:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA39630; Thu, 17 May 2001 01:48:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA39618 for ; Thu, 17 May 2001 01:47:18 -0700 (PDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H7wSb42804 for ; Thu, 17 May 2001 00:58:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from premalpc2 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA24586; Thu, 17 May 2001 01:03:26 -0700 (PDT) Reply-To: From: "Premal Ashar" To: , Subject: RE: [Isis-wg] Regarding manual area address Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 01:07:16 -0700 Content-Transfer-Encoding: 7bit Hi Amudha, When ever a L1 router knows about a L2 router it will set the attached flag for it's L1 LSP according to 7.2.9.1 of the 10589 -- Premal Ashar Member of Technical Staff Email: premal@riverstonenet.com Riverstone Networks Tel: (408)878-6515 5200 Great America Parkway FAX: (408)878-6501 Santa Clara, CA 95054 http://www.riverstonenet.com -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli Narayanan Sent: Thursday, May 17, 2001 12:37 AM To: isis-wg@juniper.net Subject: [Isis-wg] Regarding manual area address Hi, Can some one help me in understanding the attached flag? Will it be set for this setup? R1 - L1L2 router in manually configured area a1 R2 - L1L2 router in manually configured areas a1, a2. Will R1 set the attached flag as it can reach a2 via R2? Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 05:30:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12585 for ; Thu, 17 May 2001 05:30:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA40200; Thu, 17 May 2001 03:12:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA40188 for ; Thu, 17 May 2001 03:11:19 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H9MSb44986 for ; Thu, 17 May 2001 02:22:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp3.cisco.com [144.254.108.70]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA07894; Thu, 17 May 2001 10:27:27 +0100 (BST) Message-Id: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: mike shand Subject: RE: [Isis-wg] Regarding manual area address Cc: , In-Reply-To: References: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 10:27:59 +0100 At 01:07 17/05/2001 -0700, Premal Ashar wrote: >Hi Amudha, > >When ever a L1 router knows about a L2 router it will set the attached flag >for it's L1 LSP according to 7.2.9.1 of the 10589 Errr... not quite. The attached flag is set by a level 2 router in its level 1 LSP to indicate that it can reach other areas. A level 1 (only) router shouldn't be setting the attached bit, and nothing should be setting it just because it "knows about" an L2 router. The critical thing is that it can reach other areas. There are various ways it could know about this involving manual routes, but typically it is because when it runs its L2 SPF calculation it can "reach" one or more areas other than its own. And in the context of the original question, this really does mean other areas, not just other area addresses within the same area. 7.2.9.1 isn't saying anything about this. It is describing what an L1 router does with the attached bit information it sees in LSPs from other L1 routers in the area. It finds the (set of) L2 routers (within the area) which have the attached bit set, and chooses the set (possibly only one) with minimal cost. It then uses this as a "default route" for forwarding any data which is unreachable according to its L1 database. (In the CLNS case, that is if and only if the area address portion of the destination NSAP address does not match any of the local area addresses.) Mike >-- >Premal Ashar >Member of Technical Staff Email: premal@riverstonenet.com >Riverstone Networks Tel: (408)878-6515 >5200 Great America Parkway FAX: (408)878-6501 >Santa Clara, CA 95054 http://www.riverstonenet.com > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli >Narayanan >Sent: Thursday, May 17, 2001 12:37 AM >To: isis-wg@juniper.net >Subject: [Isis-wg] Regarding manual area address > > >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 09:40:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17258 for ; Thu, 17 May 2001 09:40:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41231; Thu, 17 May 2001 07:22:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41219 for ; Thu, 17 May 2001 07:21:33 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4HDWfb50799 for ; Thu, 17 May 2001 06:32:41 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4HDaYX22279; Thu, 17 May 2001 09:36:34 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-123.cisco.com [64.102.83.123]) by dingdong.cisco.com (Mirapoint) with ESMTP id AGQ24019; Thu, 17 May 2001 09:37:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20010517091642.06408ef8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Regarding manual area address Cc: In-Reply-To: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 09:22:00 -0400 Amudha, In your example, you have configured two area addresses for one area. Therefore the attached flag would not be set. Setting multiple area addresses does not place a L2 router in multiple areas, it causes multiple area addresses to be configured for the area. According to the spec, and as far as can be observed by looking at packets, no L2 router is ever in multiple areas. While there may be implementations where one can run the same router in multiple areas, these routers must make it appear to other routers as though it is a collection of routers, each in a different area. Regards, Jeff At 03:36 AM 5/17/2001, Amudhavalli Narayanan wrote: >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 10:08:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17967 for ; Thu, 17 May 2001 10:08:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41273; Thu, 17 May 2001 07:26:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41261 for ; Thu, 17 May 2001 07:25:55 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4HDb2b51040 for ; Thu, 17 May 2001 06:37:02 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 71520 invoked from network); 17 May 2001 13:42:09 -0000 Received: from unknown (HELO commsense) ([216.27.158.30]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 May 2001 13:42:09 -0000 From: "Larmer" To: "mike shand" , Cc: , Subject: RE: [Isis-wg] Regarding manual area address Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 09:43:34 -0400 Content-Transfer-Encoding: 7bit Hi, There is one other situation, which is not described by ISO-10589 where the attached bit "may" be set, depending upon the implementation. When a vendor implements multiple level-1 IS-IS instances on one IS and you want to get from one instance to another, should you set the attached bit? Well, if you set it, you can indeed get between the instances. Though, this may create problems? As long as you keep the L2 area contiguous, you should still be able to reach all other L1 areas. However, there are situations where you may take an extra hop or two to get to another area. This will happen if the L2 process does not have a direct connection to another L2 area as depicted below? _________________________________ |L2 |L2 ------------ ------------ ------ | | | | | | |L1 L1 L1| |L1 L2|-----------|L2 | ------------ ------------ ------ | | _____|_______|____ | ------- | L1 | ------- Mike??? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand Sent: Thursday, May 17, 2001 5:28 AM To: premal@riverstonenet.com Cc: amudha@future.futsoft.com; isis-wg@juniper.net Subject: RE: [Isis-wg] Regarding manual area address At 01:07 17/05/2001 -0700, Premal Ashar wrote: >Hi Amudha, > >When ever a L1 router knows about a L2 router it will set the attached flag >for it's L1 LSP according to 7.2.9.1 of the 10589 Errr... not quite. The attached flag is set by a level 2 router in its level 1 LSP to indicate that it can reach other areas. A level 1 (only) router shouldn't be setting the attached bit, and nothing should be setting it just because it "knows about" an L2 router. The critical thing is that it can reach other areas. There are various ways it could know about this involving manual routes, but typically it is because when it runs its L2 SPF calculation it can "reach" one or more areas other than its own. And in the context of the original question, this really does mean other areas, not just other area addresses within the same area. 7.2.9.1 isn't saying anything about this. It is describing what an L1 router does with the attached bit information it sees in LSPs from other L1 routers in the area. It finds the (set of) L2 routers (within the area) which have the attached bit set, and chooses the set (possibly only one) with minimal cost. It then uses this as a "default route" for forwarding any data which is unreachable according to its L1 database. (In the CLNS case, that is if and only if the area address portion of the destination NSAP address does not match any of the local area addresses.) Mike >-- >Premal Ashar >Member of Technical Staff Email: premal@riverstonenet.com >Riverstone Networks Tel: (408)878-6515 >5200 Great America Parkway FAX: (408)878-6501 >Santa Clara, CA 95054 http://www.riverstonenet.com > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli >Narayanan >Sent: Thursday, May 17, 2001 12:37 AM >To: isis-wg@juniper.net >Subject: [Isis-wg] Regarding manual area address > > >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 10:09:24 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17988 for ; Thu, 17 May 2001 10:09:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41481; Thu, 17 May 2001 07:51:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA41459 for ; Thu, 17 May 2001 07:50:01 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4HE18b51937 for ; Thu, 17 May 2001 07:01:08 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp3.cisco.com [144.254.108.70]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA23657; Thu, 17 May 2001 15:05:59 +0100 (BST) Message-Id: <4.3.2.7.2.20010517145927.035e0c78@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Larmer" From: mike shand Subject: RE: [Isis-wg] Regarding manual area address Cc: , , In-Reply-To: References: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 15:06:26 +0100 Ken, The attached bit mechanism is actually a very crude indication. The original idea was that your L2 domain should be "well connected", but when it broke you could end up with L2 routers which were isolated from the "core". You didn't want to choose one of these as your "nearest" L2 router, when there might be an "attached" router further away. But there are all sorts of scenarios which are not as black and white as this. Where the domain gets partitioned into a "big" bit and a "small" bit. How do you choose the "big" bit? Count the number of areas you can see? Propagate summary routes of the bits you can see and have multiple "nearest" L2 routers depending on which route contains the destination? etc. etc. Any attempt to solve complex problems with the existing single bit is pretty much doomed to failure. Most implementations have a combination of heuristics and manual settings which let you squeeze a bit more mileage out of this, but you can always come up with a case you can't deal with. Mike At 09:43 17/05/2001 -0400, Larmer wrote: >Hi, > > There is one other situation, which is not described >by ISO-10589 where the attached bit "may" be set, depending >upon the implementation. When a vendor implements multiple >level-1 IS-IS instances on one IS and you want to get from >one instance to another, should you set the attached bit? >Well, if you set it, you can indeed get between the instances. > > Though, this may create problems? As long as you keep >the L2 area contiguous, you should still be able to reach >all other L1 areas. However, there are situations where you >may take an extra hop or two to get to another area. This will >happen if the L2 process does not have a direct connection to >another L2 area as depicted below? > > _________________________________ > |L2 |L2 > ------------ ------------ ------ > | | | | | | > |L1 L1 L1| |L1 L2|-----------|L2 | > ------------ ------------ ------ > | | > _____|_______|____ > | > ------- > | L1 | > ------- > > > Mike??? > >Cheers, >Ken > > > > >-----Original Message----- >From: isis-wg-admin@external.juniper.net >[mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand >Sent: Thursday, May 17, 2001 5:28 AM >To: premal@riverstonenet.com >Cc: amudha@future.futsoft.com; isis-wg@juniper.net >Subject: RE: [Isis-wg] Regarding manual area address > > >At 01:07 17/05/2001 -0700, Premal Ashar wrote: > >Hi Amudha, > > > >When ever a L1 router knows about a L2 router it will set the attached flag > >for it's L1 LSP according to 7.2.9.1 of the 10589 > > >Errr... not quite. The attached flag is set by a level 2 router in its >level 1 LSP to indicate that it can reach other areas. A level 1 (only) >router shouldn't be setting the attached bit, and nothing should be setting >it just because it "knows about" an L2 router. The critical thing is that >it can reach other areas. There are various ways it could know about this >involving manual routes, but typically it is because when it runs its L2 >SPF calculation it can "reach" one or more areas other than its own. And in >the context of the original question, this really does mean other areas, >not just other area addresses within the same area. > >7.2.9.1 isn't saying anything about this. It is describing what an L1 >router does with the attached bit information it sees in LSPs from other L1 >routers in the area. It finds the (set of) L2 routers (within the area) >which have the attached bit set, and chooses the set (possibly only one) >with minimal cost. It then uses this as a "default route" for forwarding >any data which is unreachable according to its L1 database. (In the CLNS >case, that is if and only if the area address portion of the destination >NSAP address does not match any of the local area addresses.) > > Mike > > > > >-- > >Premal Ashar > >Member of Technical Staff Email: premal@riverstonenet.com > >Riverstone Networks Tel: (408)878-6515 > >5200 Great America Parkway FAX: (408)878-6501 > >Santa Clara, CA 95054 http://www.riverstonenet.com > > > >-----Original Message----- > >From: isis-wg-admin@spider.juniper.net > >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli > >Narayanan > >Sent: Thursday, May 17, 2001 12:37 AM > >To: isis-wg@juniper.net > >Subject: [Isis-wg] Regarding manual area address > > > > > >Hi, > > > >Can some one help me in understanding the attached flag? > > > >Will it be set for this setup? > > > >R1 - L1L2 router in manually configured area a1 > >R2 - L1L2 router in manually configured areas a1, a2. > > > >Will R1 set the attached flag as it can reach a2 via R2? > > > >Thanks, > >Amudha > > > > > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 15:38:31 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25629 for ; Thu, 17 May 2001 15:38:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA42951; Thu, 17 May 2001 13:20:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA40130 for ; Thu, 17 May 2001 03:01:42 -0700 (PDT) Received: from mail16.bigmailbox.com (mail16.bigmailbox.com [209.132.220.47]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4H9Cqb44793 for ; Thu, 17 May 2001 02:12:52 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail16.bigmailbox.com (8.8.7/8.8.7) id CAA20009; Thu, 17 May 2001 02:17:52 -0700 Message-Id: <200105170917.CAA20009@mail16.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [61.135.52.146] From: "R Selvaraj" To: isis-wg@juniper.net Cc: selvarajr@www.com Subject: [Isis-wg] ISIS over tunnel Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 02:17:52 -0700 Content-Transfer-Encoding: binary Hi, It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? Pls let me know. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 17 20:24:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29189 for ; Thu, 17 May 2001 20:24:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA44177; Thu, 17 May 2001 18:00:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA44159 for ; Thu, 17 May 2001 17:59:07 -0700 (PDT) Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4I0AAb93901 for ; Thu, 17 May 2001 17:10:10 -0700 (PDT) X-JNPR-Received-From: outside Received: from q.nexthop.com ([141.211.130.163]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f4I0FHh20281; Thu, 17 May 2001 20:15:17 -0400 (EDT) (envelope-from chopps@q.nexthop.com) Received: (from chopps@localhost) by q.nexthop.com (8.11.0/8.11.0) id f4I0FFk19748; Thu, 17 May 2001 20:15:15 -0400 (EDT) From: "Christian E . Hopps" To: R Selvaraj Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] ISIS over tunnel Message-ID: <20010517201515.V3146@nexthop.com> References: <200105170917.CAA20009@mail16.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105170917.CAA20009@mail16.bigmailbox.com>; from selvarajr@www.com on Thu, May 17, 2001 at 02:17:52AM -0700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 20:15:15 -0400 On Thu, May 17, 2001 at 02:17:52AM -0700, R Selvaraj wrote: > Hi, > It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? > Pls let me know. You can use EON (ISO in IP) tunnels. I'm not sure if they are standardized anywhere, but I modified NetBSD's gif tunnels to support EON encapsulation if you want a code reference. The code interoperates with at least one popular (:) router vendor. Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 18 01:49:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07950 for ; Fri, 18 May 2001 01:49:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA45496; Thu, 17 May 2001 23:31:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA45484 for ; Thu, 17 May 2001 23:30:50 -0700 (PDT) Received: from redd99.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4I5fob02001 for ; Thu, 17 May 2001 22:41:50 -0700 (PDT) X-JNPR-Received-From: outside Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd99.procket.com (8.9.3/8.9.3) with ESMTP id WAA30963; Thu, 17 May 2001 22:46:58 -0700 X-Confidential: Procket Confidential/Need to know Message-ID: <3B04B752.3C88F133@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tony Przygienda CC: isis-wg@juniper.net Subject: Re: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> <3B03187A.D475065E@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 22:46:58 -0700 Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > > Derek Yeung wrote: > > > Tony Przygienda wrote: > > > > > > Derek Yeung wrote: > > > > > > > Hi, > > > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > > > > > Thanks, > > > > - Derek > > > > ________________________________ > > > > > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > > > There was some serious feet-dragging there and change of ADs just happened > > > as well. I hope to see the RFC out anytime soon ... > > > > > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. > > > > Any big change between the 01 draft and the final RFC ? If there is no important > > change, my copy would be good enough. > > don't remember what 01 was but the only change that pretty much ever came up was the issue > of whehter you calculate csum first or authentication. Nischal caught that when implementing. > > > BTW, I have a few questions about the 01 draft. > > > > The draft said one cannot rely on authentication as checksum mechanism. > > Does the draft refer to simple cleartext authentication in particular or any authentication > > scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, > > in OSPF, checksum is not calculated when MD5 authentication is used. The only problem > > I see is that one cannot tell whether error is due to packet corruption or > > real authentication failure, but it is probably not a big deal. > > well, source authentication should imply integrity in security so it's kind of true what you're > saying. > However, this clear text password is a glaring hole here (it's basically not authentication ;-) > So having said that, we could add a sentence or so to the draft saying that if it's clear that > authentication verifies integrity of the packet, checksum can be omitted. Read on ... > > > The draft also said that an implemenation that implements optional checksum MUST > > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? > > very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more > important to not Not brain-twisted at all, I found it pretty obvious ;-) > make the assumption that someone MUST put optional checksums on packets (equivalent to > saying that you MUST NOT or MAY only accept packets without optional checksums). That > would render piles of existing deployment problematic and lead to nasty effects when > boxes are misconfigured. Also, that would introduce even more dependencies with the previous point > you brought up since you'd have to say > e.g. "must accept pdus which do not contain optional checksum if md5 is present". then of course > think about the case where the checksum tlv got corrupted so it's not present anymore AND > md5 got corrupted to deliver correct verification for that corrupted packet. Worst of all I think > saying that "you must not accept packets without optional checksum when you expect it" would > prevent in future boxes from being shipped with optional checksums enabled as default which I'd like > to see ideally. All that doesn't end and has a 0.00001% of a chance > to show up in real networks ;-) IHMO, "you must not accept packets without optional checksum when you expect it" is the right thing to do. Just a different opinion, no big deal. > > To summarize, I'd like to keep MD5 and checksums decoupled for simplicity reasons > and only resolve the dependency which > one's to be computed/verified first when received so I'd resist either change you brought up. > > - -tony I am not proposing to couple MD5 and checksum in the same draft. My point is just that if MD5 authentication has been implemented already, there is no significant technical reason to implement optional checksum too. Thanks, - Derek _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 18 02:02:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11855 for ; Fri, 18 May 2001 02:02:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA45587; Thu, 17 May 2001 23:44:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA45575 for ; Thu, 17 May 2001 23:43:14 -0700 (PDT) Received: from mail4.bigmailbox.com (mail4.bigmailbox.com [209.132.220.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4I5sFb02197 for ; Thu, 17 May 2001 22:54:15 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail4.bigmailbox.com (8.8.7/8.8.7) id WAA15044; Thu, 17 May 2001 22:59:02 -0700 Message-Id: <200105180559.WAA15044@mail4.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [61.135.46.205] From: "R Selvaraj" To: chopps@nexthop.com Cc: isis-wg@juniper.net Subject: RE: Re: [Isis-wg] ISIS over tunnel Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 22:59:02 -0700 Content-Transfer-Encoding: binary Hi, I would like to know the procedure for implementing ISIS over GRE tunnel. I'm basically looking for some document/URL in that regard. Pls let me know. Thanks, Selva. >From: "Christian E . Hopps" >To: R Selvaraj >Cc: isis-wg@juniper.net >SUBJECTDate: Thu, 17 May 2001 20:15:15 -0400 > >On Thu, May 17, 2001 at 02:17:52AM -0700, R Selvaraj wrote: >> Hi, >> It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? >> Pls let me know. > >You can use EON (ISO in IP) tunnels. I'm not sure if they are standardized >anywhere, but I modified NetBSD's gif tunnels to support EON encapsulation >if you want a code reference. The code interoperates with at least one >popular (:) router vendor. > >Chris. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat May 19 01:58:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27864 for ; Sat, 19 May 2001 01:58:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA51322; Fri, 18 May 2001 23:39:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA51310 for ; Fri, 18 May 2001 23:38:21 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4J5nBb84406 for ; Fri, 18 May 2001 22:49:11 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.48.145]) by mta7.pltn13.pbi.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0GDK007QZJ2I33@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Fri, 18 May 2001 22:54:19 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Optional Checksum in ISIS To: Derek Yeung Cc: isis-wg@juniper.net Message-id: <3B06072D.4B67F874@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> <3B03187A.D475065E@redback.com> <3B04B752.3C88F133@procket.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 May 2001 22:39:57 -0700 Content-Transfer-Encoding: 7bit Derek Yeung wrote: > > > The draft also said that an implemenation that implements optional checksum MUST > > > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > > > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > > > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? > > > > very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more > > important to not > > Not brain-twisted at all, I found it pretty obvious ;-) ok > > prevent in future boxes from being shipped with optional checksums enabled as default which I'd like > > to see ideally. All that doesn't end and has a 0.00001% of a chance > > to show up in real networks ;-) > > IHMO, "you must not accept packets without optional checksum when you expect it" is the > right thing to do. Just a different opinion, no big deal. ok, agreed to disagree here .... maybe more people will comment. > > and only resolve the dependency which > > one's to be computed/verified first when received so I'd resist either change you brought up. > I am not proposing to couple MD5 and checksum in the same draft. well, if we start to put in the draft all kind of sentences as of what to do conditionally if either MD5 is present or not, we'll end up coupling those issues together. > My point is just that > if MD5 authentication has been implemented already, there is no significant technical reason > to implement optional checksum too. agree technically, observe that with the way the draft is stated you are free to ignore CSUMs if MD5 is configured and omit them in your packets. Things will still work. So in a sense there is no need to specifically state that you HAVE TO omit them. thanks -=-= tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 21 04:40:18 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03954 for ; Mon, 21 May 2001 04:40:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA65177; Mon, 21 May 2001 02:21:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA65165 for ; Mon, 21 May 2001 02:20:26 -0700 (PDT) Received: from mail11.bigmailbox.com (mail11.bigmailbox.com [209.132.220.42]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4L8Utb23554 for ; Mon, 21 May 2001 01:30:55 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail11.bigmailbox.com (8.8.7/8.8.7) id BAA30169; Mon, 21 May 2001 01:36:12 -0700 Message-Id: <200105210836.BAA30169@mail11.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [202.108.17.138] From: "R Selvaraj" To: isis-wg@juniper.net Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 21 May 2001 01:36:12 -0700 Content-Transfer-Encoding: binary Hi, Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. It'll be helpful if I get clarified. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 21 11:36:52 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11325 for ; Mon, 21 May 2001 11:36:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA66821; Mon, 21 May 2001 09:18:07 -0700 (PDT) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA66809 for ; Mon, 21 May 2001 09:17:38 -0700 (PDT) Received: from w2kamir ([192.168.2.97]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 21 May 2001 18:33:30 +0300 Message-ID: <059c01c0e20b$857c5710$6102a8c0@cwnt.com> From: "Amir H." To: "ISIS-wg" Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-01.txt Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0599_01C0E224.AA9ED590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 21 May 2001 15:33:30.0569 (UTC) FILETIME=[63595390:01C0E20B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 21 May 2001 18:34:27 +0300 This is a multi-part message in MIME format. ------=_NextPart_000_0599_01C0E224.AA9ED590 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Hi, a new version of the LSP fragments draft has been submitted. Please take a moment to examine it, and reply with your thoughts. Editorial comments should be sent to me, please. General comments to the list. Main things that were changed were editorial and clarifications. Thanks, Amir Hermelin mailto:amir@cwnt.com Charlotte's Web Networks LTD. http://www.cwnt.com Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with ISIS implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. ------=_NextPart_000_0599_01C0E224.AA9ED590 Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-01.txt" Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-01.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Amir Hermelin Internet Draft Charlotte's Web Networks, Inc. Expiration Date: November 2001 Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit draft-hermelin-ext-lsp-frags-01.txt Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with ISIS implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. A. Hermelin Expires November 2001 [Page 1] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 1. Introduction In the IS-IS protocol, a system floods its link-state information in Link State Protocol Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO 10589 [1] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate. A number of factors can contribute to exceeding this limit: - Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The growing size of route tables and AS topologies. This document describes a mechanism to relax the limit on the number of LSP fragments, while providing behavior that would allow previous implementations to correctly process fragments exceeding this limit. 1.1 Definitions of Commonly Used Terms This section provides definitions for terms that are used throughout the text. Originating System A router running the IS-IS protocol. Original system-id The system-id of an originating system. Extended system-id An additional system-id that is assigned by the network administrator. Each extended system-id allows generation of 256 additional, or extended, LSP fragments. The extended system-id, like the original system-id, must be unique throughout the routing domain. Virtual System The system, identified by an extended system-id, advertised as originating the extended LSP fragments. These fragments specify the extended system-id in their LSP IDs. Original LSP An LSP using the original system-id in its LSP ID. A. Hermelin Expires November 2001 [Page 2] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Extended LSP An LSP using an extended system-id in its LSP ID. LSP set A group of LSP fragments constituting a logical LSP. These share a specific system-id and pseudonode number, and differ only in their LSP (or fragment) Number. Extended LSP set A group of LSP fragments using an extended system-id, and originated by the originating system. These fragments appear to other routers as having been originated by the virtual system identified by an extended system-id. 1.2 Overview Using additional system-ids assigned to the originating system, that system can advertise the excess link-state information in extended LSPs under these extended system-ids. It would do so as if other routers, or "virtual systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the originating system may generate extended LSPs under numerous virtual systems. The originating system will not advertise its extended system-ids to any of its neighbors; it will always use its original system-id in IS Hellos [3] and IS-IS Hellos. As a result, no adjacencies will be formed with other systems using extended system-ids, and the originating system would be the only one advertising adjacencies to its extended system-ids, as described below. The originating system must include connectivity information in its original LSPs (the LSPs with the original system-id in their LSP ID) to all virtual systems for which extended LSPs are generated by it. This is to ensure other routers correctly process the extra information in their SPF calculation. The metric for these connections should be zero, since the cost of reaching a virtual system is the same as the cost of reaching its originating system. To other routers, virtual systems would appear reachable only through their originating system, hence loss of connectivity to the originating system means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non- extended LSPs is the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop. A. Hermelin Expires November 2001 [Page 3] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 +---------------------------------------------+ | Originating System | | system-id =3D S | | ( extended system-ids =3D S', S'' ) | +---------------------------------------------+ | /\ | /\ cost=3D0 | |cost=3Dmax cost=3D0 | |cost=3Dmax | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id =3D S' | | system-id =3D S'' | +------------------+ +------------------+ Figure 1. Advertising connections to virtual systems The generation of extended LSPs is discussed in section 2. Not all link-state information that can be advertised in the original LSPs can be advertised in extended LSPs; this is discussed in further detail in section 3. However, most "leaf" information, i.e. information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs. Other routers exhibit the same behavior for this information as for information advertised in the original LSPs, with a few minor exceptions noted in section 5. Extended LSPs can be purged, in the same manner as original LSPs. This is discussed in section 4. 2. Generating Extended LSP Fragments When new extended LSP fragments are generated, these fragments should be generated as specified in ISO 10589 [1]. Furthermore, a system will treat its extended LSPs the same as it treats its original LSPs, with the exceptions noted in section 3. Specifically, creating, flooding, renewing, purging and all other operations are similar for both original and extended LSPs, unless stated otherwise. The extended LSPs will use one of the extended system-ids configured for the router, in their LSP ID. An extended LSP Number zero should be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. Additionally, when an extended LSP belonging to extended system-id S' is first created, the original LSP must specify S' as a neighbor, with metric set to zero. This is to ensure other routers will consider the extended LSP in their SPF A. Hermelin Expires November 2001 [Page 4] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 calculations, as well as consider the cost of reaching the virtual system S' the same as the cost of reaching its originating system. Furthermore, the extended LSP must specify the original system-id as a neighbor, with metric set to MaxLinkMetric. Where relevant, this adjacency should be considered as point-to-point. Note, that the restriction specified in ISO 10589 section 7.2.5 holds: if an LSP Number zero of the originating system is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well. Extended LSPs with number zero will be regarded in the same special manner as specified in 10589 for LSPs with number zero, and will include the same type of extra information as specified in 10589 and RFC 1195 [2]. So, for example, when a system reissues its LSP Number zero due to an area address change, it should reissue all extended LSPs with number zero as well. 3. Exceptions when Encoding Extended LSP Fragments 3.1 The LSP Header The LSP header of an extended LSP fragment should include the same settings as for non-extended LSP fragments with the exceptions noted below: 3.1.1 The Pseudonode ID The Pseudonode ID, which is part of the LSP ID, should be set to zero on all extended LSP fragments. 3.1.2 The Attached Bits The Attached (ATT) bits should be set to zero for all four metric types, on all extended LSPs. This is for two main reasons: - If a virtual system is reachable, so is its originating system. It is preferable, then, that an L1 IS chooses the originating system and not the virtual system as its nearest L2 exit point, as connectivity to the virtual system has a higher probability of being lost (a result of the extended LSP no longer being advertised). This could cause unnecessary processing on some implementations. - Some implementations which support weighted multipath, might set A. Hermelin Expires November 2001 [Page 5] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 multipath weights according to the number of ISs that can be reached via each path. So, for example, if there are two nearest L2 ISs to a particular L1-only system, each reachable via different interfaces, and one is generating an extended LSP, then the L1 system might forward more traffic towards that destination (i.e. give it a stronger weight), as it would think it is forwarding traffic towards two L2 ISs. 3.1.3 The Partition Repair Bit The Partition Repair (P) bit should be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits. 3.2 TLVs Extended LSPs can contain any TLVs that original LSPs can contain, with the exceptions noted below. 3.2.1 IS Neighbors TLV An Extended LSP must specify only the originating system as a neighbor, with the metric set to MaxLinkMetric. No other neighbors may be specified in an Extended LSP, as this would not satisfy the bi-directionality check in the SPF calculation. Where relevant, this adjacency should be considered as point-to-point. 3.2.2 ES Neighbors TLV ISO 10589 [1] section 7.3.7 specifies inserting an ES Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195 [2] relieves IP- only routers of this requirement. However, for routers that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI-capable), then in an extended LSP, the relevant extended system-id should be used. Furthermore, OSI-capable routers should accept packets destined for this extended system-id. 4. Purging Extended LSP Fragments ISO 10589 [1] section 7.3.4.4 note 21 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. A. Hermelin Expires November 2001 [Page 6] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 These recommendations hold for the extended LSP fragments as well. However, an extended LSP Number zero should not be purged until all of the fragments in its set (i.e. belonging to a particular virtual system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF calculations, as specified in section 7.2.5. When all the extended LSP fragments of a particular extended system- id S' have been purged, the originating system should remove the adjacency information to S' from its original LSPs. 5. Compatibility Issues Previous implementations will interpret TLVs in extended LSPs in the same manner that they interpret TLVs in original LSPs, due to the zero metric adjacencies from the originating system to its virtual systems. However, applications that take hop count into consideration, will misinterpret the destinations appearing in extended LSPs as being one hop further than they really are. This is due to the extra neighbor hop needed to reach these LSPs. There are two solutions to this problem: - Add extra information to specify that an adjacency should not be considered for any purpose of hop counting. - Restrict information that might be subject to hop counting, such as traffic engineering information, to appear only in the original LSPs. These restrictions should be applied with care, as too many of them could re-introduce the problem of limited LSP fragments. 6. Security Considerations This document raises no new security issues for IS-IS. 7. Acknowledgments The author would like to thank Tony Li, Radia Perlman, and Mike Shand for helpful ideas and suggestions on the subject. 8. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the A. Hermelin Expires November 2001 [Page 7] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] ISO 9542, "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", March 1988 9. Author's Address Amir Hermelin Charlotte's Web Networks, Inc. 2 Hamada St. Yokneam Moshava, 26000 ISRAEL Email: amir@cwnt.com Phone: +972 4 9592203 Fax: +972 4 9593325 A. Hermelin Expires November 2001 [Page 8] =0C ------=_NextPart_000_0599_01C0E224.AA9ED590-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 22 16:02:32 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02842 for ; Tue, 22 May 2001 16:02:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA73487; Tue, 22 May 2001 13:44:09 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA73475 for ; Tue, 22 May 2001 13:43:52 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4MJs6b94597 for ; Tue, 22 May 2001 12:54:06 -0700 (PDT) X-JNPR-Received-From: outside Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4MJvwc06084 for ; Tue, 22 May 2001 12:57:58 -0700 (PDT) Received: from cisco.com (irp-view7.cisco.com [171.69.25.24]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABX11792 (AUTH sluong); Tue, 22 May 2001 12:59:19 -0700 (PDT) Message-ID: <3B0AC516.FC7F6250@cisco.com> From: Steven Luong X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net References: <200102272326.SAA20260@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] draft-ietf-isis-hmac Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 22 May 2001 12:59:18 -0700 Content-Transfer-Encoding: 7bit What is the latest status of the subject draft? I can't find it anymore in the ietf web site. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 22 16:17:10 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03241 for ; Tue, 22 May 2001 16:17:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA73612; Tue, 22 May 2001 13:59:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA73600 for ; Tue, 22 May 2001 13:58:09 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4MK8Nb95240 for ; Tue, 22 May 2001 13:08:23 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 61EB4F69C01; Tue, 22 May 2001 13:13:45 -0700 (PDT) Message-ID: <3B0AC4E9.BE988B06@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steven Luong Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-hmac References: <200102272326.SAA20260@bcn.East.Sun.COM> <3B0AC516.FC7F6250@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 22 May 2001 12:59:02 -0700 Content-Transfer-Encoding: 7bit Steven Luong wrote: > What is the latest status of the subject draft? I can't find it anymore in the ietf web > site. check with rja, pls. Last time we talked he was supposed to update it and put it out thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 23 03:45:28 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28706 for ; Wed, 23 May 2001 03:45:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA76341; Wed, 23 May 2001 01:28:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA76329 for ; Wed, 23 May 2001 01:27:32 -0700 (PDT) Received: from mail14.bigmailbox.com (mail14.bigmailbox.com [209.132.220.45]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4N7bfb15058 for ; Wed, 23 May 2001 00:37:41 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail14.bigmailbox.com (8.8.7/8.8.7) id AAA20691; Wed, 23 May 2001 00:43:04 -0700 Message-Id: <200105230743.AAA20691@mail14.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [61.135.52.134] From: "R Selvaraj" To: isis-wg@juniper.net Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 May 2001 00:43:04 -0700 Content-Transfer-Encoding: binary Hi, Let me resend my last doubt. Actually, I would like to know wheather a L12 router shall include its local L2 circits IP adress in its L1 LSP's Internal Reach TLV and vice versa for its L2 LSP. Thanks, Selva. >From: "R Selvaraj" >To: isis-wg@juniper.net >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > >Hi, >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > >It'll be helpful if I get clarified. > >Thanks, >Selva. > > > > >------------------------------------------------------------ >WWW.COM - Where the Web Begins! http://www.www.com >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 23 09:56:46 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05299 for ; Wed, 23 May 2001 09:56:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA78066; Wed, 23 May 2001 07:38:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA78054 for ; Wed, 23 May 2001 07:37:34 -0700 (PDT) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4NDlfb23454 for ; Wed, 23 May 2001 06:47:41 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 1079 invoked from network); 23 May 2001 13:53:05 -0000 Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 May 2001 13:53:05 -0000 From: "Ken Larmer" To: , "R Selvaraj" Cc: "Ken Larmer" Subject: RE: [Isis-wg] Doubt regarding IP Internal Reach TLV Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200105230743.AAA20691@mail14.bigmailbox.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 May 2001 09:53:19 -0400 Content-Transfer-Encoding: 7bit Hi Selva, My inclination would be to only place L1 routes into L1 LSPs and L2 routes into L2 LSPs. However, I just conducted some testing on a well-known platform and the results are a bit puzzling? If I have 2 circuits, both set to circuit-type L1/L2, one circuit has adjacencyUsage = L1/L2 (matching area) and the other with adjacencyUsage = L2-Only (no matching area), I get the following results: L1 LSP IP Internal Reachability Information = IP subnets from both circuits L2 LSP IP Internal Reachability Information = IP subnets from both circuits When I change the circuit which does not have a matching area to "circuit-type = L2-Only", so that I now have two circuits with adjacencyUsage = L1/L2 (matching area) and adjacencyUsage = L2-Only (non-matching area and circuit-type = L2-Only), I get the following results: L1 LSP IP Internal Reachability Information = IP subnet from circuit with adjacencyUsage = L1/L2 L2 LSP IP Internal Reachability Information = IP subnets from both circuits ???? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of R Selvaraj Sent: Wednesday, May 23, 2001 3:43 AM To: isis-wg@juniper.net Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Hi, Let me resend my last doubt. Actually, I would like to know wheather a L12 router shall include its local L2 circits IP adress in its L1 LSP's Internal Reach TLV and vice versa for its L2 LSP. Thanks, Selva. >From: "R Selvaraj" >To: isis-wg@juniper.net >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > >Hi, >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > >It'll be helpful if I get clarified. > >Thanks, >Selva. > > > > >------------------------------------------------------------ >WWW.COM - Where the Web Begins! http://www.www.com >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 23 14:13:10 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11455 for ; Wed, 23 May 2001 14:13:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79171; Wed, 23 May 2001 11:55:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79156 for ; Wed, 23 May 2001 11:54:41 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4NI4jb36470 for ; Wed, 23 May 2001 11:04:46 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f4NI9A416273; Wed, 23 May 2001 11:09:10 -0700 From: Henk Smit Message-Id: <200105231809.f4NI9A416273@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Doubt regarding IP Internal Reach TLV To: selvarajr@www.com (R Selvaraj) Cc: isis-wg@juniper.net In-Reply-To: <200105230743.AAA20691@mail14.bigmailbox.com> from "R Selvaraj" at May 23, 2001 12:43:04 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 May 2001 11:09:10 -0700 (PDT) Content-Transfer-Encoding: 7bit I haven't checked rfc1195, but the following has always been my understanding. > Let me resend my last doubt. > Actually, I would like to know wheather a L12 router shall include its > local L2 circits IP adress in its L1 LSP's Internal Reach TLV No. Routers inside an area should only know about "things" that are living inside that area. "Things" include routers, adjacencies, IP prefixes. If a L1L2 router has prefix-X configured on a L2-only circuit, then IMHO that prefix-X is not part of the L1 area, and thus the L1L2 router should not advertise prefix-X in its L1 LSP. Prefix-X will be reachable because the L1L2 router has the "attached bit" set in its L1 LSP. (Unless this router can not reach other areas, then it doesn't set the attached-bit, and L1-only routers can not reach prefix-X. Too bad, such is life). If a L1L2 router implements the extensions from RFC2966, then a L1L2 router is allowed to advertise all or any of the IP prefixes it has learned via L2 router. This includes directly connected prefixes configured on L2-only circuits. > and vice versa for its L2 LSP. A L1L2 router is responsable for reachability from the L2 backbone to all IP prefixes that live inside its L1 area. Therefor a L1L2 router must advertise all IP prefixes that live in its L1 area, inside its L2 LSP. IMHO this includes all IP prefixes configured on directly connected L1-only circuits. Of course when you configure summary-addresses, individual L1 prefixes might not be advertised in the L2 LSP, because they are covered by the summary address. So the "problem" that you see is that a L1L2 router advertises the IP prefixes configured on L2-only circuits in its L1 LSP ? Well, IMHO that would not be necessary. But it wouldn't hurt eiter. (Except for the fact that the L1 LSP would be a little bigger. No big deal). The benefit of doing this would be the case I pointed out above. If the L1L2 router looses contact to other areas, it will unset the attached bit in its L1 LSP. Then L1-only routers would not be able to reach the IP prefixes configured on the L2-only circuits of the L1L2 router. If a router always advertises the prefixes configured on its L2-only circuits in its L1 LSP, then this problem will not occur. Hope this helps, henk. > Thanks, > Selva. > > > >From: "R Selvaraj" > >To: isis-wg@juniper.net > >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > > > >Hi, > >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > > > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > > > >It'll be helpful if I get clarified. > > > >Thanks, > >Selva. > > > > > > > > > >------------------------------------------------------------ > >WWW.COM - Where the Web Begins! http://www.www.com > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 02:40:42 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06875 for ; Thu, 24 May 2001 02:40:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA82255; Thu, 24 May 2001 00:22:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA82243 for ; Thu, 24 May 2001 00:21:25 -0700 (PDT) Received: from cwnt.com ([192.116.246.129]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4O6VNb62842 for ; Wed, 23 May 2001 23:31:24 -0700 (PDT) X-JNPR-Received-From: outside Received: from W2Komer ([192.168.2.99]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 24 May 2001 09:36:59 +0300 Message-ID: <033101c0e41b$e9f26240$6302a8c0@cwnt.com> Reply-To: "Omer Sali" From: "Omer Sali" To: "Ken Larmer" , References: Subject: Re: [Isis-wg] Doubt regarding IP Internal Reach TLV Organization: CWNT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 24 May 2001 06:36:59.0023 (UTC) FILETIME=[EEEE79F0:01C0E41B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 09:36:50 +0300 Content-Transfer-Encoding: 7bit Hi Ken, The IP Internal Reachability Information includes all the subnets ISIS knows from all the interfaces it runs on. The RFC says nothing about a condition like: "advertise only IP's of interfaces you have an adjacency over them". For example, in section 1.3 of RFC 1195 you can find: "Specifically, zero or more [IP address, subnet mask, metric] combinations may be included in each Link State Packet. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations which are reachable on each interface. " So, in the first case you have discribed you had ISIS running on the interface at level 1 so you saw the IP address advertised in the L1 LSP (although you had no adjacency on L1). In the second case ISIS did not ran on L1 so the router did not advertise it in its L1 LSPs. By the way, most implementations allow you to run ISIS on an interface in "passive mode" saying: "don't exchange packets (don't raise adjacencies) but advertise the IP of the interface as IP Internal Reachability". Hope it helps, Omer ----- Original Message ----- From: "Ken Larmer" To: ; "R Selvaraj" Cc: "Ken Larmer" Sent: Wednesday, May 23, 2001 4:53 PM Subject: RE: [Isis-wg] Doubt regarding IP Internal Reach TLV > Hi Selva, > > My inclination would be to only place L1 routes into L1 LSPs and L2 routes > into L2 LSPs. > > However, I just conducted some testing on a well-known platform and the > results are a bit puzzling? If I have 2 circuits, both set to circuit-type > L1/L2, one circuit has adjacencyUsage = L1/L2 (matching area) and the other > with adjacencyUsage = L2-Only (no matching area), I get the following > results: > > L1 LSP IP Internal Reachability Information = IP subnets from both circuits > L2 LSP IP Internal Reachability Information = IP subnets from both circuits > > When I change the circuit which does not have a matching area to > "circuit-type = L2-Only", so that I now have two circuits with > adjacencyUsage = L1/L2 (matching area) and adjacencyUsage = L2-Only > (non-matching area and circuit-type = L2-Only), I get the following results: > > L1 LSP IP Internal Reachability Information = IP subnet from circuit with > adjacencyUsage = L1/L2 > L2 LSP IP Internal Reachability Information = IP subnets from both circuits > > ???? > > Cheers, > Ken > > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of R Selvaraj > Sent: Wednesday, May 23, 2001 3:43 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV > > Hi, > Let me resend my last doubt. Actually, I would like to know wheather a L12 > router shall include its local L2 circits IP adress in its L1 LSP's Internal > Reach TLV and vice versa for its L2 LSP. > > Thanks, > Selva. > > > >From: "R Selvaraj" > >To: isis-wg@juniper.net > >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > > > >Hi, > >Section 5.3.4 of RFC 1195 states that IP addresses within the routing > domain reachable directly via one or more interfaces on the router should be > encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, > do we need to consider circuit level also. I mean, a L12 router while > encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all > of its L1 circit's IP address and should not consider its L2 circuit's IP > address at all. > > > >I found some implementation, for L12 router, not encodeing L2 circuit's IP > address in its L1 LSP's IP Internal Reach TLV. > > > >It'll be helpful if I get clarified. > > > >Thanks, > >Selva. > > > > > > > > > >------------------------------------------------------------ > >WWW.COM - Where the Web Begins! http://www.www.com > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 10:00:55 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13658 for ; Thu, 24 May 2001 10:00:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84174; Thu, 24 May 2001 07:43:07 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84162 for ; Thu, 24 May 2001 07:42:14 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4ODqAb71566 for ; Thu, 24 May 2001 06:52:10 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Omer Sali'" , Ken Larmer , isis-wg@juniper.net Subject: RE: [Isis-wg] Doubt regarding IP Internal Reach TLV MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E459.7325E720" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 09:57:20 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E459.7325E720 Content-Type: text/plain; charset="iso-8859-1" > By the way, most implementations allow you to run ISIS on an > interface in "passive mode" saying: "don't exchange packets > (don't raise adjacencies) but advertise the IP of the > interface as IP Internal Reachability". > > Omer > > > I would like to know wheather a L12 > > router shall include its local L2 circits IP adress in its L1 LSP's > > Internal Reach TLV and vice versa for its L2 LSP. > > > > Selva. I thought the issue was that there was no point in advertising that you can reach a network if you have no evidence that you can, in fact, reach the network. Just because you are configured and you have carrier doesn't mean that you can get there from here. The existence of an IS-IS Adjacency on a link proves that there is at least one other router under the delusion that it can reach the net in question. Implementations use "passive" to bring in networks that do not have other IS-IS routers on it: the assumption is that the administrator has performed extra due-diligence on the link, much as he would with a static configuration. - jeff parker - axiowave networks ------_=_NextPart_001_01C0E459.7325E720 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Doubt regarding IP Internal Reach TLV

> By the way, most implementations allow you to run ISIS on an
> interface in "passive mode" saying: "don't exchange packets
> (don't raise adjacencies) but advertise the IP of the
> interface as IP Internal Reachability".
>
> Omer
>
> > I would like to know wheather a L12
> > router shall include its local L2 circits IP adress in its L1 LSP's
> > Internal Reach TLV and vice versa for its L2 LSP.
> >
> > Selva.

I thought the issue was that there was no point in advertising
that you can reach a network if you have no evidence that you
can, in fact, reach the network.  Just because you are configured
and you have carrier doesn't mean that you can get there from
here. 

The existence of an IS-IS Adjacency on a link proves that
there is at least one other router under the delusion that
it can reach the net in question.  Implementations use
"passive" to bring in networks that do not have other IS-IS
routers on it: the assumption is that the administrator
has performed extra due-diligence on the link, much as he
would with a static configuration.  

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0E459.7325E720-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 13:02:03 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17216 for ; Thu, 24 May 2001 13:02:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA84998; Thu, 24 May 2001 10:44:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA84986 for ; Thu, 24 May 2001 10:43:39 -0700 (PDT) Received: from mail20.bigmailbox.com (mail20.bigmailbox.com [209.132.220.51]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4OGrYb79399 for ; Thu, 24 May 2001 09:53:34 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail20.bigmailbox.com (8.8.7/8.8.7) id JAA09802; Thu, 24 May 2001 09:59:02 -0700 Message-Id: <200105241659.JAA09802@mail20.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [202.108.17.133] From: "R Selvaraj" To: isis-wg@juniper.net Cc: jparker@axiowave.com Subject: Re:Re: [Isis-wg] Doubt regarding IP Internal Reach TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 09:59:02 -0700 Content-Transfer-Encoding: binary >I thought the issue was that there was no point in advertising >that you can reach a network if you have no evidence that you >can, in fact, reach the network. Just because you are configured >and you have carrier doesn't mean that you can get there from >here. >The existence of an IS-IS Adjacency on a link proves that >there is at least one other router under the delusion that >it can reach the net in question. --Jeff Parker Do u mean that unless an ISIS have an ajacency on the circuit it should not include the circit IP addres ? But, even if there is no adjacency on the circuit it can still route data packtets to that net. I feel an ISIS need not bother about adjacency for advertising Internal reachability information. Neighhbour TLV can do that. Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 13:40:11 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17909 for ; Thu, 24 May 2001 13:40:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA85219; Thu, 24 May 2001 11:23:09 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA85202 for ; Thu, 24 May 2001 11:22:35 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4OHWTb81420 for ; Thu, 24 May 2001 10:32:29 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4OHa8X03384; Thu, 24 May 2001 13:36:08 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-123.cisco.com [64.102.83.123]) by dingdong.cisco.com (Mirapoint) with ESMTP id AGY02042; Thu, 24 May 2001 13:37:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20010524133406.019745e0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "R Selvaraj" From: Jeff Learman Subject: Re:Re: [Isis-wg] Doubt regarding IP Internal Reach TLV Cc: isis-wg@juniper.net, jparker@axiowave.com In-Reply-To: <200105241659.JAA09802@mail20.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 13:36:24 -0400 At 12:59 PM 5/24/2001, R Selvaraj wrote: >>I thought the issue was that there was no point in advertising >>that you can reach a network if you have no evidence that you >>can, in fact, reach the network. Just because you are configured >>and you have carrier doesn't mean that you can get there from >>here. > >>The existence of an IS-IS Adjacency on a link proves that >>there is at least one other router under the delusion that >>it can reach the net in question. >--Jeff Parker I assume you mean "router or host", not just router, and are including adjacencies created by ARP as well as IS adjacencies. Otherwise, how would we ever get a route to a subnet with only one router? Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 14:41:39 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18812 for ; Thu, 24 May 2001 14:41:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA85513; Thu, 24 May 2001 12:24:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA62997 for ; Sun, 20 May 2001 17:34:07 -0700 (PDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4KNieb16460 for ; Sun, 20 May 2001 16:44:40 -0700 (PDT) X-JNPR-Received-From: outside Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.66.28]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA09948; Sun, 20 May 2001 19:45:57 -0400 (EDT) From: Russ White Reply-To: Russ White To: Tony Przygienda cc: Derek Yeung , isis-wg@juniper.net Subject: Re: [Isis-wg] Optional Checksum in ISIS In-Reply-To: <3B06072D.4B67F874@redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 20 May 2001 19:49:48 -0400 (EDT) > > My point is just that if MD5 authentication has been > > implemented already, there is no significant technical reason > > to implement optional checksum too. > > agree technically, observe that with the way the draft is > stated you are free to ignore CSUMs if MD5 is configured and > omit them in your packets. Things will still work. So in a > sense there is no need to specifically state that you HAVE TO > omit them. I'll agree with Tony here, and say we should leave it optional. Of course, I'd expect implementations to ignore the checksum if md5 is enabled, just as a matter of efficiency. It won't matter if anyone actually sends them if everyone ignores them when md5 is enabled, so we'll all end up not sending them either, most likely. :-) Russ _____________ riw@cisco.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 14:42:01 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18834 for ; Thu, 24 May 2001 14:42:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA85551; Thu, 24 May 2001 12:25:02 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA83795 for ; Thu, 24 May 2001 06:08:14 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4OCHkb69125 for ; Thu, 24 May 2001 05:17:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA04348 for ; Thu, 24 May 2001 17:02:10 +0530 From: "Sivakumar A" Message-Id: <200105241132.RAA04348@WS0005.indiatimes.com> To: Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637" MIME-Version: 1.0 Subject: [Isis-wg] ES/IS options in an LSP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 16:54:52 +0530 --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637 Content-Type: text/plain; charset=us-ascii Hi all, In an LSP why should all Intermediate System Neighbour options always precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) Section 9.8 page No. 55. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637 Content-Type: text/html; charset=us-ascii

Hi all,

In an LSP why should all Intermediate System Neighbour options always precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) Section 9.8 page No. 55.

Thanks and regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 24 14:42:20 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18844 for ; Thu, 24 May 2001 14:42:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA85529; Thu, 24 May 2001 12:24:46 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA83764 for ; Thu, 24 May 2001 06:05:40 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4OCFYb69076 for ; Thu, 24 May 2001 05:15:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA04569 for ; Thu, 24 May 2001 17:09:32 +0530 From: "Sivakumar A" Message-Id: <200105241139.RAA04569@WS0005.indiatimes.com> To: Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340" MIME-Version: 1.0 Subject: [Isis-wg] Virtual adjacencies Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 May 2001 17:02:13 +0530 --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340 Content-Type: text/plain; charset=us-ascii Hello all, Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV. Thanks in advance sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340 Content-Type: text/html; charset=us-ascii

Hello all,

Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV.

 

Thanks in advance

sivakumar

 

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 25 04:52:08 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13595 for ; Fri, 25 May 2001 04:52:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA89238; Fri, 25 May 2001 02:34:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA89226 for ; Fri, 25 May 2001 02:33:24 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4P8hCb10597 for ; Fri, 25 May 2001 01:43:12 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp11.cisco.com [144.254.108.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA05730; Fri, 25 May 2001 09:48:07 +0100 (BST) Message-Id: <4.3.2.7.2.20010525094713.01e00f38@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Sivakumar A" From: mike shand Subject: Re: [Isis-wg] Virtual adjacencies Cc: In-Reply-To: <200105241139.RAA04569@WS0005.indiatimes.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 May 2001 09:48:43 +0100 At 17:02 24/05/2001 +0530, Sivakumar A wrote:

Hello all,

Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV.

No, you can put multiple virtual adjacencies within the same TLV. You just have to have separate TLVs for virtual and non-virtual.

But you are not seriously considering implementing partition repair are you?

        Mike


 

Thanks in advance

sivakumar

 

 
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
_______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 25 05:04:57 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13693 for ; Fri, 25 May 2001 05:04:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA89319; Fri, 25 May 2001 02:46:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA89307 for ; Fri, 25 May 2001 02:45:52 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4P8teb10827 for ; Fri, 25 May 2001 01:55:40 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp11.cisco.com [144.254.108.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA06219; Fri, 25 May 2001 10:00:35 +0100 (BST) Message-Id: <4.3.2.7.2.20010525095133.01e00960@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Sivakumar A" From: mike shand Subject: Re: [Isis-wg] ES/IS options in an LSP Cc: In-Reply-To: <200105241132.RAA04348@WS0005.indiatimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 May 2001 10:00:28 +0100 At 16:54 24/05/2001 +0530, Sivakumar A wrote: >Hi all, > >In an LSP why should all Intermediate System Neighbour options always >precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) >Section 9.8 page No. 55. Didn't we just discuss this? Its an attempt to avoid having to move options from one LSP to another. So the idea was to keep the (more stable) IS information together and leave the ES information to flap around at the end. Some implementations put the IS information in LSPs starting at zero and working up, and ES information starting at 255 and working down. It doesn't really buy you all that much. See also 7.3.4.4 Mike >Thanks and regards > >Sivakumar A > >---------- >Get Your Private, Free E-mail from Indiatimes at >http://email.indiatimes.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 14:29:53 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08584 for ; Tue, 29 May 2001 14:29:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16277; Tue, 29 May 2001 12:13:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA09184 for ; Mon, 28 May 2001 06:06:08 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4SCFNb77611 for ; Mon, 28 May 2001 05:15:24 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA05630 for "isis"; Mon, 28 May 2001 17:31:22 +0530 From: "Sivakumar A" Message-Id: <200105281201.RAA05630@WS0005.indiatimes.com> To: "isis" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299" MIME-Version: 1.0 Subject: [Isis-wg] improper LSP no. Sequence Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 May 2001 17:38:16 +0530 --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299 Content-Type: text/plain; charset=us-ascii Hello all, all IS adjacencies should preceed ES adjacencies according to ISO 10589. if an LSP with LSP no. 5 containing all ES adjacencies is received and later LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated Thanks in advance sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299 Content-Type: text/html; charset=us-ascii

Hello all,

all IS adjacencies should preceed ES adjacencies according to ISO 10589. if  an LSP with LSP no. 5 containing all ES adjacencies is received and later  LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated

Thanks in advance

sivakumar A

 

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 14:31:37 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08644 for ; Tue, 29 May 2001 14:31:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16322; Tue, 29 May 2001 12:15:25 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA14198 for ; Tue, 29 May 2001 03:21:44 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4T9Upb96651 for ; Tue, 29 May 2001 02:30:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id OAA04049 for "isis"; Tue, 29 May 2001 14:46:39 +0530 From: "Sivakumar A" Message-Id: <200105290916.OAA04049@WS0005.indiatimes.com> To: "isis" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227" MIME-Version: 1.0 Subject: [Isis-wg] Usage of Pt-to-Pt Circuit Id Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 14:53:34 +0530 --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227 Content-Type: text/plain; charset=us-ascii Hello all, Why is Pt-to-Pt Circuit ID is calculated and where it is used? Any help regarding this is appretiated. Thanks in advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227 Content-Type: text/html; charset=us-ascii

Hello all,

Why is Pt-to-Pt Circuit ID is calculated and where it is used? Any help regarding this is appretiated.

Thanks in advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 14:31:58 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08661 for ; Tue, 29 May 2001 14:31:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16306; Tue, 29 May 2001 12:15:09 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA13356 for ; Tue, 29 May 2001 00:25:06 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4T6YEb93295 for ; Mon, 28 May 2001 23:34:14 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA29831 for "isis"; Tue, 29 May 2001 11:50:03 +0530 From: "Sivakumar A" Message-Id: <200105290620.LAA29831@WS0005.indiatimes.com> To: "isis" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127" MIME-Version: 1.0 Subject: [Isis-wg] LSP 0 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 11:42:39 +0530 --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127 Content-Type: text/plain; charset=us-ascii Hello all, Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? For Example: If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Please give your valuable comments. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127 Content-Type: text/html; charset=us-ascii

Hello all,

Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode?

For Example:

If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode?

Please give your valuable comments.

Thanks and regards

Sivakumar A     

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 14:32:02 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08671 for ; Tue, 29 May 2001 14:32:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16339; Tue, 29 May 2001 12:15:41 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA15959 for ; Tue, 29 May 2001 11:01:46 -0700 (PDT) Received: from mailweb5.rediffmail.com ([202.54.124.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4THAob12937 for ; Tue, 29 May 2001 10:10:50 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 2851 invoked by uid 510); 29 May 2001 17:22:04 -0000 Message-ID: <20010529172204.2850.qmail@mailweb5.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 29 May 2001 17:22:04 -0000 MIME-Version: 1.0 To: "isis-wg@juniper.net" CC: "jparker@axiowave.com" From: "A Rama suryanarayana" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [Isis-wg] querry regarding draft-ietf-isis-wg-mib-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 May 2001 17:22:04 -0000 Content-Transfer-Encoding: 7bit Hello, When i was going through the MIB for implementing Integrated IS-IS, I could not find the configurable object IP Interface address. The IP interface address should go with the Hellos, LSPs according to RFC 1195. can any one tell me How IP interface address are configured. any help regarding this is appriatiated. Thanks in advance Warm Regards suryanarayana _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 14:59:27 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09176 for ; Tue, 29 May 2001 14:59:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16645; Tue, 29 May 2001 12:43:09 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16633 for ; Tue, 29 May 2001 12:42:42 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4TIpjb18468 for ; Tue, 29 May 2001 11:51:45 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'A Rama suryanarayana'" , isis-wg@juniper.net Cc: Jeff Parker MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E871.20DD81F0" Subject: [Isis-wg] RE: querry regarding draft-ietf-isis-wg-mib-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 14:56:54 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E871.20DD81F0 Content-Type: text/plain; charset="iso-8859-1" > Hello, > When i was going through the MIB for implementing > Integrated IS-IS, I could not find the configurable object IP > Interface address. The IP interface address should go with > the Hellos, LSPs according to RFC 1195. can any one tell me > How IP interface address are configured. any help regarding > this is appriatiated. > > Thanks in advance > > Warm Regards > suryanarayana I would think that RFC 1213, or whatever has replaced it, would be the place to go for this funcitonality. - jeff parker ------_=_NextPart_001_01C0E871.20DD81F0 Content-Type: text/html; charset="iso-8859-1" RE: querry regarding draft-ietf-isis-wg-mib-04.txt

> Hello,
>   When i was going through the MIB for implementing
> Integrated IS-IS, I could not find the configurable object IP
> Interface address. The IP interface address should go with
> the Hellos, LSPs according to RFC 1195. can any one tell me
> How IP interface address are configured. any help regarding
> this is appriatiated.
>
> Thanks in advance
>
> Warm Regards
> suryanarayana

I would think that RFC 1213, or whatever has replaced it,
would be the place to go for this funcitonality.  

- jeff parker

------_=_NextPart_001_01C0E871.20DD81F0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 15:01:57 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09259 for ; Tue, 29 May 2001 15:01:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16693; Tue, 29 May 2001 12:46:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16681 for ; Tue, 29 May 2001 12:45:21 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4TIsPb18622 for ; Tue, 29 May 2001 11:54:25 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f4TJ02U12006; Tue, 29 May 2001 12:00:02 -0700 From: Henk Smit Message-Id: <200105291900.f4TJ02U12006@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] improper LSP no. Sequence To: sivaa@indiatimes.com Cc: isis-wg@juniper.net (isis) In-Reply-To: <200105281201.RAA05630@WS0005.indiatimes.com> from "Sivakumar A" at May 28, 2001 05:38:16 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 12:00:02 -0700 (PDT) Content-Transfer-Encoding: 7bit > all IS adjacencies should preceed ES adjacencies according to ISO 10589. if an LSP with LSP no. 5 containing all ES adjacencies is received and later LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated This is an IETF WG. The most important rule in IETF protocols has always been: "Be strict in what you send, be liberal in what you accept". So, *IMHO*, you should never drop an LSP because it does the ordering of TLVs in the wrong way. As Mike Shand has explained, the ordering of IS TLVs at the beginning of an LSP (or set of LSP fragments), and ES TLVs at the end of an LSP (or set of LSP fragments), is a way to optimize and prevent unnecessary fragment changes. This is an optimization to try to minimize the amount of LSP fragments being flooded. There are no substantial reasons why you shouldn't accept those LSP fragments. Nothing in the routing will break if you do. So *IMHO* you should build your implementation in such a way that it will accept those LSPs, even if they don't have the TLVs in the right order. Hope this helps, henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 15:03:21 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09305 for ; Tue, 29 May 2001 15:03:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16744; Tue, 29 May 2001 12:47:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA16712 for ; Tue, 29 May 2001 12:46:54 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4TItwb18705 for ; Tue, 29 May 2001 11:55:58 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f4TJ1aS12029; Tue, 29 May 2001 12:01:36 -0700 From: Henk Smit Message-Id: <200105291901.f4TJ1aS12029@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] LSP 0 To: sivaa@indiatimes.com Cc: isis-wg@juniper.net (isis) In-Reply-To: <200105290620.LAA29831@WS0005.indiatimes.com> from "Sivakumar A" at May 29, 2001 11:42:39 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 12:01:36 -0700 (PDT) Content-Transfer-Encoding: 7bit > Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? > > For Example: > > If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Yes. In fact, each pseudonode LSP, as well as each non-pseudonode LSP, is required to have an LSP fragment number zero. henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 29 15:20:54 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09578 for ; Tue, 29 May 2001 15:20:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA16863; Tue, 29 May 2001 13:02:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA16851 for ; Tue, 29 May 2001 13:01:08 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4TJABb19506 for ; Tue, 29 May 2001 12:10:11 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Sivakumar A'" , isis Subject: RE: [Isis-wg] Usage of Pt-to-Pt Circuit Id MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E873.C3458490" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 15:15:46 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E873.C3458490 Content-Type: text/plain; charset="iso-8859-1" > Why is Pt-to-Pt Circuit ID is calculated and where it is used? One place this is used is in the three-way handshake describe by Katz and Saluja in "Three-Way Handshake for IS-IS Point-to- Point Adjacencies" which seems to have aged off the workgroup page. It is used there to detect that the remote side has heard your hellos. It's a form of active listening, repeating what you have just heard, and allows you to detect some anomalous one-way connected situations. - jeff parker - axiowave networks ------_=_NextPart_001_01C0E873.C3458490 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Usage of Pt-to-Pt Circuit Id

> Why is Pt-to-Pt Circuit ID is calculated and where it is used? 

One place this is used is in the three-way handshake describe
by Katz and Saluja in "Three-Way Handshake for IS-IS Point-to-
Point Adjacencies" which seems to have aged off the workgroup
page. 

It is used there to detect that the remote side has heard your
hellos.  It's a form of active listening, repeating what you
have just heard, and allows you to detect some anomalous one-way
connected situations. 

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0E873.C3458490-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 30 04:00:24 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03337 for ; Wed, 30 May 2001 04:00:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA19957; Wed, 30 May 2001 01:44:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA19945 for ; Wed, 30 May 2001 01:43:25 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4U7w6w17602 for ; Wed, 30 May 2001 00:58:06 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com ([10.49.188.189]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA26106; Wed, 30 May 2001 08:57:24 +0100 (BST) Message-Id: <4.3.2.7.2.20010530083948.01a74d98@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henk Smit From: mike shand Subject: Re: [Isis-wg] improper LSP no. Sequence Cc: sivaa@indiatimes.com, isis-wg@juniper.net (isis) In-Reply-To: <200105291900.f4TJ02U12006@redd3174.procket.com> References: <200105281201.RAA05630@WS0005.indiatimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 May 2001 08:42:25 +0100 At 12:00 29/05/2001 -0700, Henk Smit wrote: > > all IS adjacencies should preceed ES adjacencies according to ISO > 10589. if an LSP with LSP no. 5 containing all ES adjacencies is > received and later LSP no. 8 with IS adjacencies is received, should an > implementation discard this LSP(no. 8) or the Complete set of LSP's > received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is > appretiated > > This is an IETF WG. The most important rule in IETF protocols has > always been: > > "Be strict in what you send, be liberal in what you accept". > > So, *IMHO*, you should never drop an LSP because it does the ordering > of TLVs in the wrong way. As Mike Shand has explained, the ordering > of IS TLVs at the beginning of an LSP (or set of LSP fragments), and > ES TLVs at the end of an LSP (or set of LSP fragments), is a way to > optimize and prevent unnecessary fragment changes. This is an optimization > to try to minimize the amount of LSP fragments being flooded. There > are no substantial reasons why you shouldn't accept those LSP fragments. > Nothing in the routing will break if you do. So *IMHO* you should > build your implementation in such a way that it will accept those > LSPs, even if they don't have the TLVs in the right order. No need to be humble about it Henk :-) You should definitely accept those LSPs. Mike > Hope this helps, > > henk. > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 30 13:45:18 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19441 for ; Wed, 30 May 2001 13:45:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA22663; Wed, 30 May 2001 11:29:08 -0700 (PDT) Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA17927 for ; Tue, 29 May 2001 17:03:52 -0700 (PDT) Received: from tot-tq.proxy.aol.com (tot-tq.proxy.aol.com [152.163.201.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id TAA05441 for ; Tue, 29 May 2001 19:18:21 -0400 (EDT) Received: from ma.ultranet.com (AC9D30CF.ipt.aol.com [172.157.48.207]) by tot-tq.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f4TNIH609573 for ; Tue, 29 May 2001 19:18:17 -0400 (EDT) Message-ID: <3B1458C1.B37EC7A2@ma.ultranet.com> From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Hudeks@aol.com Subject: [Isis-wg] History of the External Metric Type? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 May 2001 19:19:45 -0700 Content-Transfer-Encoding: 7bit Hi all, Before embarking on an ISIS implementation, I've been perusing the wg mail archives, and I want to make sure I understand the current status of the (effectively deprecated?) "external metric type" indication (or perhaps more clearly, the non-comparable metric type indication). The following is my current understanding... please let me know if it's correct or if I've gone delusional ;-) (and if the latter, what the real situation is, thanks :-) ) When the spec was first defined, it was thought that users might want to inject routes into ISIS from other sources, and those other routes might come in two flavors: a) those using metrics which are directly comparable with the metrics used by ISIS, and b) those using metrics which are NOT comparable with the metrics used by ISIS. The "metric type" indication was defined as a mechanism for distinguishing between these two types, with the comparable metrics being identified as "internal metric type", and the non-comparable metrics being identified as "external metric type" Only the internal metric type was valid for IP Internal Reachability information. Either internal or external metric type would be valid for IP External Reachability information. IP External Reachability info using internal metric type would be treated similarly to Internal Reachability info, but IP External Reachability info would be less preferred if it used external metric type instead. Then, the RealWorld(TM) intervened :-) In the dominant early implementation (presumably cisco's), the internal/external metric type field was accidentally ignored, and all IP Reachability was treated as having internal metric type. No one complained. It is presumed (known??) that this is because customers never actually made use of the external metric type capability, rather than because they did try to use it but then never noticed odd but still workable routes chosen because of comparing what were intended to be incomparable metrics. As long as every interworking implementation calculated things in the same manner, loops were avoided, and things worked out in a manner satisfactory to the customers. Subsequent implementations by others either also ignored the external metric type, or provided a configurable knob to turn its recognition on/off for compatibility purposes and everyone was(is) just turning it off. So far there has apparently not been any hue and cry for the restoration of the capability, and as a practical matter everyone is fine with only using comparable metrics. Given that IP External Reachability with internal metrics is treated similarly to IP Internal Reachability, and that IP External Reachability with external metrics is not actually used in practice, there no longer appears to be any significant difference between IP Internal/External Reachability, and so no longer any need for separate TLVs. Given all that, and being practical folks, as new enhancements were proposed, they were(are) no longer explicitly including the capability of distinguishing between internal/external metric type. For instance, (if I'm reading it correctly) the ISIS extensions for TE draft-rfc intentionally leaves out any internal/external metric type, as well as lumping together all IP Reachability into one (extended) type. Going forward, the net effect seems to be a deprecation of the comparable/noncomparable metric idea, in favor of all IP reachability info using a single comparable metric type. There exists the possibility for subTLVs in the IP Extended Reachability, but so far no-one has publicly defined any subTLVs to revive the internal/external (comparable/noncomparable) metric type distinction. The above is my best guess as to the current state of affairs, treating what had been implied in some earlier emails as explicitly true. How far off am I ? :-) Assuming that the above isn't too far off the mark, assuming that implementations will not properly interwork if they calculate routes differently (and that they will calculate routes differently if one recognizes external metrics and treats them differently from internal, while another does not recognize external metrics or does but still treats them the same as internal), would it be reasonable for the external metric type to be "officially" deprecated and implementers strongly encouraged to ignore the external metric type if encountered (a "send yours as internal only, and ignore theirs" sort of deal), treating all as internal metric type ? adTHANKSvance, dave h _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 30 13:46:28 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19477 for ; Wed, 30 May 2001 13:46:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA22714; Wed, 30 May 2001 11:30:23 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA21852 for ; Wed, 30 May 2001 08:15:08 -0700 (PDT) Received: from mailweb18.rediffmail.com ([203.199.83.142]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4UETkw27350 for ; Wed, 30 May 2001 07:29:46 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 11946 invoked by uid 510); 30 May 2001 14:34:32 -0000 Message-ID: <20010530143432.11945.qmail@mailweb18.rediffmail.com> Received: from unknown (202.108.17.199) by rediffmail.com via HTTP; 30 May 2001 14:34:32 -0000 MIME-Version: 1.0 To: "sivaa@indiatimes.com" , "isis-wg@juniper.net" Subject: Re: [Isis-wg] LSP 0 From: "R selvaraj" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 30 May 2001 14:34:32 -0000 Content-Transfer-Encoding: 7bit Pseudonode LSPs are generated behalf of pseudonode, a virtial node. So, always think pseudonode as a seperate node. Also it has it own unique soure ID(7 bytes). Although the same router(physically) is originating both Pseudonode as well as non-pseudonode LSPs both are considered to be from two different sources. Since each source should start LSP generation from LSP 0 , obviously the same router should generate LSP 0 for pseudonode as well as non-pseudonode. If suppose the router has 10 broadcast interfaces and if all the 10 interfaces are DR then the router will be having 11 LSPs with LSP number 0(10 Pseudonode LSP + 1 non-pseudonode LSP). Selva. ------------- Original Message -------------- "Sivakumar A" wrote: To:"isis" From:"Sivakumar A" Date:Tue, 29 May 2001 11:42:39 +0530 Subject:[Isis-wg] LSP 0 Hello all, Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? For Example: If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Please give your valuable comments. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 30 13:48:16 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19530 for ; Wed, 30 May 2001 13:48:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA22698; Wed, 30 May 2001 11:30:12 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA21273 for ; Wed, 30 May 2001 06:23:49 -0700 (PDT) Received: from mailweb32.rediffmail.com ([203.199.83.152]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f4UCcRw23316 for ; Wed, 30 May 2001 05:38:28 -0700 (PDT) X-JNPR-Received-From: outside Received: (qmail 22799 invoked by uid 510); 30 May 2001 12:42:40 -0000 Message-ID: <20010530124240.22798.qmail@mailweb32.rediffmail.com> Received: from unknown (202.108.17.199) by rediffmail.com via HTTP; 30 May 2001 12:42:40 -0000 MIME-Version: 1.0 To: "isis-wg@juniper.net" From: "Purushothaman NandaKumaran" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Reachability information passing Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 30 May 2001 12:42:40 -0000 Content-Transfer-Encoding: 7bit Hi, I have some doubts regarding the following: 1) Whether the internal reachability information in the Level 2 LSP (about level 2 subdomain)can be passed on to the level 1 area through level1 LSP's? 2) Whether the external reachability information (e.g learnt thru BGP) can be passed to the routers in level 1 area thru level 1 LSP's? Please clarify my doubts Thanks and Regards, Purush _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 30 14:25:58 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20662 for ; Wed, 30 May 2001 14:25:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA22974; Wed, 30 May 2001 12:10:08 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA22959 for ; Wed, 30 May 2001 12:09:01 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4UINcw39674 for ; Wed, 30 May 2001 11:23:38 -0700 (PDT) X-JNPR-Received-From: outside Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f4UIIAT13983; Wed, 30 May 2001 11:18:10 -0700 From: Henk Smit Message-Id: <200105301818.f4UIIAT13983@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Reachability information passing To: purush_isis@rediffmail.com (Purushothaman NandaKumaran) Cc: isis-wg@juniper.net (isis-wg@juniper.net) In-Reply-To: <20010530124240.22798.qmail@mailweb32.rediffmail.com> from "Purushothaman NandaKumaran" at May 30, 2001 12:42:40 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 May 2001 11:18:09 -0700 (PDT) Content-Transfer-Encoding: 7bit > Hi, > I have some doubts regarding the following: > 1) Whether the internal reachability information in the Level 2 LSP > (about level 2 subdomain)can be passed on to the level 1 > area through level1 LSP's? In the original ISIS for IP specification (RFC 1195), there was no way to do that. Network operators have asked for this feature later, and it has been implemented, and has been documented in RFC 2966. > 2) Whether the external reachability information (e.g learnt thru BGP) > can be passed to the routers in level 1 area thru level 1 LSP's? In RFC 1195 that wasn't allowed either. However, some vendors implemented redistribution into L1 anyway. This was documented later in rfc2966 as well. http://www.ietf.org/rfc/rfc2966.txt henk. > Please clarify my doubts > Thanks and Regards, > Purush _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg