From isis-wg-admin@ietf.org Thu May 1 17:25:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11946 for ; Thu, 1 May 2003 17:25:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LQv811055; Thu, 1 May 2003 17:26:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41LLx810849 for ; Thu, 1 May 2003 17:21:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11382 for ; Thu, 1 May 2003 17:15:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLQl-0006w6-00 for isis-wg@ietf.org; Thu, 01 May 2003 17:17:27 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19BLQf-0006vd-00 for isis-wg@ietf.org; Thu, 01 May 2003 17:17:21 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 17:16:50 -0400 Some comments on draft-ietf-isis-restart-03.txt. The biggest request is for a FSM describing the state transitions for the starting router and it's helpers. The comments below are for clarity: I don't think I understand the protocol well enough to comment. Indented text is quote from draft or proposed alternative. Outdented text is commentary. page 1 "This is necessary in order to invoke the protocol mechanisms to ensure correct synchronization of the LSP database." But you go on to demonstrate that it -isn't- necessary. page 2 "This draft additionally describes a mechanism to optimize database synchronization and minimize transient routing disruption when a router starts." I'd suggest something to flag the difference between this and the restarting case, as this is the first time this is encountered. Perhaps replace the last line of the three above with "router starts without wishing to reuse prior adjacencies." "Firstly, when a routing process restarts and an adjacency to a neighboring router is reinitialized the neighboring routing process does three things:" The point of view changes from that of the restarting router to the peer. Something like the following keeps in focused in place "When a router's peer restarts and the peer adjacency is reinitialized, the router does three things:" This issue appears in other places. I think it would be helpful to introduce terminology to describe three or four entities: The restarting router Could be split into starting router and restarting router An aware and helpful peer I don't recall needing an aware and unwilling peer A peer who is not aware of the protocol The names could be fanciful (Phoenix, Newborn, Samaratin, and Innocent) or more prosaic: Restarter, Rebooter, Helper, and Bystander. Page 3 "1. It reinitializes the adjacency and causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database." And the third? If only for balance, you should say something about the third. "It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits." Does this also belong in the overview, as an assumption? "An instance of T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated." It is not clear to me what an "unacknowledged restart attempt" is. I assume this is sending out the hello packets with the special TLV, but it could be read to include (re)setting the timers. "A single instance of T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set." We can expect one of at least two policies from the Samaritans: a fixed time, and the remaining time left on the adjacency. Any suggestions on policies, or time required for a reboot? Is this a configuration parameter? A MIB parameter? page 4 "Type 211 Length 3 Value (3 octets) Flags (1 octet) Bit 1 - Restart Request (RR) Bit 2 - Restart Acknowledgment (RA) Bit 3 - Suppress adjacency advertisement(SA) Bits 4-8 - Reserved Remaining Time (2 octets) Remaining holding time (in seconds) (note: only required when RA bit is set)" Do we need to think about versioning? We -can- always append more fields. "b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, having updated the "Point-to- Point Adjacency State" option to reflect any new values received from the (re)starting router." Any new values? I presume this only means the link ID. System ID should not change (if it does, the restart won't work) we should not restate our Link ID, and this does not apply to the 3way state field. Marking what you are looking for explicit will clear up questions. Page 5 "Both restarting and starting routers will make use of the RR bit in the restart TLV, though at different stages of the (re)start procedure." I found this a bit easier to read "Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use them at different stages of the (re)start procedure." page 6 "On receipt of an IIH by the restarting router, a local adjacency is..." Consider "When a restarting router receives an IIH, a local adjacency is..." "T3 is set to the minimum of its current value and the value of the" Consider "The global timer T3 is set ..." page 7 "When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled." And then what happens? We don't send IIH with RR bit set? We start the SPF? Perhaps a FSM for restart and Samaritan would help. page 8 4.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring Suggest you start the section with something to suggest the transition. "Next we turn to the case of a router starting, without assuming any prior adjacencies." - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 10:45:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16683 for ; Fri, 2 May 2003 10:45:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42EnX827334; Fri, 2 May 2003 10:49:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Emo827311 for ; Fri, 2 May 2003 10:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16609 for ; Fri, 2 May 2003 10:41:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BblU-0004gW-00 for isis-wg@ietf.org; Fri, 02 May 2003 10:43:56 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16] helo=p-mail2) by ietf-mx with smtp (Exim 4.12) id 19BblO-0004fw-00 for isis-wg@ietf.org; Fri, 02 May 2003 10:43:50 -0400 Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Fri, 02 May 2003 16:48:57 +0200 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 2 May 2003 16:43:04 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Message-ID: Thread-Topic: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Thread-Index: AcMQJ/PG+UZ9OGkwSU2NDQ9vdQ2dsAAisOvg From: "DUBOIS Nicolas FTRD/DAC/ISS" To: "Jeff Parker" , "ISIS-WG (E-mail)" X-OriginalArrivalTime: 02 May 2003 14:43:04.0424 (UTC) FILETIME=[23547E80:01C310B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42Emo827312 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 May 2003 16:43:02 +0200 Content-Transfer-Encoding: 8bit At FT R&D we also strongly support a FSM description, it would greatly support our testing and interop efforts, as FSM for both restarting and helping routers are complex. We tried to figure out on diagrams what was and should be happening in different cases, but our efforts were not very satisfactory due to the multiple timers system. Trying to figure out what should be the best timer settings in the case of our network was also very difficult from a theoretical and modelling point of view. Anyway in the lab it seems to be working in most cases. Part of that, >I don't think I understand the protocol well enough >to comment. Same for me :-) Our current thought (not very advanced) on graceful restart are: It could definetely help in case of maintenance operations if it were possible to activate and deactivate it in a simple manner. Official engineering rules recommend using the overload bit, using Graceful Restart could be an inprovement. It is deployed on some routers that activate it by default ... but we do not know if it has proven useful or not. Equivalent question is : "do you prefer a simple or a complex fire detection system " in a situation where unexpected events that are candidate for Graceful Restart should never happen in our networks and knowing that we do not check wether a graceful restart did occur or not in case of such events. When we'll have deployed a powerful enough metrology system in order to confirm whether an ISIS Graceful Restart was or wasn't successful in real network conditions, we'll tell you that we absolutely need to have it working as stated in the draft. Even though it is out of the scope of this working group ... one other thing we would support and find useful is a simple detection mechanism for lost hellos (or expected hellos that do not come in the expected timeframe) as this would help having finer granularity in the approximation of link reliability at the IS-IS level. Having this granularity would help us tell you wether we need graceful restart or not. Best regards, Nicolas Dubois core packet network lab France Telecom R&D -----Message d'origine----- De : Jeff Parker [mailto:jparker@axiowave.com] Envoyé : jeudi 1 mai 2003 23:17 À : ISIS-WG (E-mail) Objet : [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Some comments on draft-ietf-isis-restart-03.txt. The biggest request is for a FSM describing the state transitions for the starting router and it's helpers. The comments below are for clarity: I don't think I understand the protocol well enough to comment. Indented text is quote from draft or proposed alternative. Outdented text is commentary. page 1 "This is necessary in order to invoke the protocol mechanisms to ensure correct synchronization of the LSP database." But you go on to demonstrate that it -isn't- necessary. page 2 "This draft additionally describes a mechanism to optimize database synchronization and minimize transient routing disruption when a router starts." I'd suggest something to flag the difference between this and the restarting case, as this is the first time this is encountered. Perhaps replace the last line of the three above with "router starts without wishing to reuse prior adjacencies." "Firstly, when a routing process restarts and an adjacency to a neighboring router is reinitialized the neighboring routing process does three things:" The point of view changes from that of the restarting router to the peer. Something like the following keeps in focused in place "When a router's peer restarts and the peer adjacency is reinitialized, the router does three things:" This issue appears in other places. I think it would be helpful to introduce terminology to describe three or four entities: The restarting router Could be split into starting router and restarting router An aware and helpful peer I don't recall needing an aware and unwilling peer A peer who is not aware of the protocol The names could be fanciful (Phoenix, Newborn, Samaratin, and Innocent) or more prosaic: Restarter, Rebooter, Helper, and Bystander. Page 3 "1. It reinitializes the adjacency and causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database." And the third? If only for balance, you should say something about the third. "It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits." Does this also belong in the overview, as an assumption? "An instance of T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated." It is not clear to me what an "unacknowledged restart attempt" is. I assume this is sending out the hello packets with the special TLV, but it could be read to include (re)setting the timers. "A single instance of T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set." We can expect one of at least two policies from the Samaritans: a fixed time, and the remaining time left on the adjacency. Any suggestions on policies, or time required for a reboot? Is this a configuration parameter? A MIB parameter? page 4 "Type 211 Length 3 Value (3 octets) Flags (1 octet) Bit 1 - Restart Request (RR) Bit 2 - Restart Acknowledgment (RA) Bit 3 - Suppress adjacency advertisement(SA) Bits 4-8 - Reserved Remaining Time (2 octets) Remaining holding time (in seconds) (note: only required when RA bit is set)" Do we need to think about versioning? We -can- always append more fields. "b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, having updated the "Point-to- Point Adjacency State" option to reflect any new values received from the (re)starting router." Any new values? I presume this only means the link ID. System ID should not change (if it does, the restart won't work) we should not restate our Link ID, and this does not apply to the 3way state field. Marking what you are looking for explicit will clear up questions. Page 5 "Both restarting and starting routers will make use of the RR bit in the restart TLV, though at different stages of the (re)start procedure." I found this a bit easier to read "Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use them at different stages of the (re)start procedure." page 6 "On receipt of an IIH by the restarting router, a local adjacency is..." Consider "When a restarting router receives an IIH, a local adjacency is..." "T3 is set to the minimum of its current value and the value of the" Consider "The global timer T3 is set ..." page 7 "When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled." And then what happens? We don't send IIH with RR bit set? We start the SPF? Perhaps a FSM for restart and Samaritan would help. page 8 4.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring Suggest you start the section with something to suggest the transition. "Next we turn to the case of a router starting, without assuming any prior adjacencies." - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 12:30:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19772 for ; Fri, 2 May 2003 12:30:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GZH803771; Fri, 2 May 2003 12:35:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GY8803700 for ; Fri, 2 May 2003 12:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19671 for ; Fri, 2 May 2003 12:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdPL-0005Qw-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:29:11 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19BdPF-0005Qm-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:29:05 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h42GSqua009461 for ; Fri, 2 May 2003 09:28:52 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-1052.cisco.com [10.21.100.28]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW00499; Fri, 2 May 2003 09:21:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20030502091700.00b87580@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@ietf.org From: Les Ginsberg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Comment on draft-ietf-isis-hmac-04.txt and draft-ietf-isis-traffic-05.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 09:28:51 -0700 The above two drafts reference RFC 1142. They should not. RFC 1142 was published in 1990 based on an early draft of what eventually became ISO 10589:1992. As such, it contains a number of defects which were corrected prior to the publication of the 1992 ISO standard. Because of this it should NOT be used as a reference for the protocol. As I recall, a number of questions have been brought to this list over the years because some folks thought that RFC 1142 was a legitimate reference and rediscovered defects which had long ago been corrected. It would be a good thing if RFC 1142 was moved to OBSOLETE status. In any case, drafts should not reference this RFC. Now that the second edition of ISO 10589 is an official standard, it would also be good if drafts referenced the newer version: "ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition." Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 12:47:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20355 for ; Fri, 2 May 2003 12:47:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gq8805531; Fri, 2 May 2003 12:52:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gpx805498 for ; Fri, 2 May 2003 12:51:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20215 for ; Fri, 2 May 2003 12:44:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bdgc-0005Z2-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:47:02 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19BdgW-0005Xd-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:46:56 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 May 2003 12:46:18 -0400 > An earlier version of the draft had an FSM. It was removed based on > feedback. (Hard to please everyone I guess.) We will consider > adding it back in. Thanks. > > "This is necessary in order to invoke the protocol > > mechanisms to ensure correct synchronization of the LSP > database." > > > >But you go on to demonstrate that it -isn't- necessary. > > How about: > > "This invokes the protocol mechanisms which ensure correct > synchronization of the LSP database." Works for me > >I'd suggest something to flag the difference between this and the > >restarting case, as this is the first time this is encountered. > >Perhaps replace the last line of the three above with > > > > "router starts without wishing to reuse prior adjacencies." > > The terms "restart/restarting","start/starting", and > "(re)start/(re)starting" are very carefully defined so as to > try to avoid > confusion. (I like these better than "Phoenix", etc.) But the > definitions > occur AFTER the Abstract, which makes this first usage > ambiguous. I am > thinking we need to make the ABSTRACT much shorter and then > use much of the > current abstract as an introduction AFTER the terms have been defined. There are two issues: the text in this case, which caught me unprepared for the difference you were discussing between start and restart, and the general case. This case can be handled by flagging the difference. For the general case, I find starting and restarting very close, and thus confusing. I agree that the terms are carefully defined. > >The point of view changes from that of the restarting router to > >the peer. Something like the following keeps in focused in place > > > > "When a router's peer restarts and the peer adjacency > > is reinitialized, the router does three things:" > > How about: > > "When an adjacency is reinitialised as a result of a > neighbor restating, the router does 3 things:". I think I know whose point of view we have here, but I'm still not certain. Adding "router's" helps me. "When a router's adjacency is reinitialised as a result of a neighbor restating, the router does 3 things:". > >This issue appears in other places. I think it would be helpful > >to introduce terminology to describe three or four entities: > > I was hoping the terms defined in the "Conventions" section > would be both clear and sufficient. These are all suggestions: take those which help you. > >Page 3 > > "1. It reinitializes the adjacency and causes its own > LSP(s) to be > > regenerated, thus triggering SPF runs throughout > the area (or > > in the case of Level 2, throughout the domain). > > > > 2. It sets SRMflags on its own LSP database on the adjacency > > concerned. > > > > 3. In the case of a Point-to-Point link it transmits a (set of) > > CSNP(s) over the adjacency. > > > > In the case of a restarting router process, the first of these is > > highly undesirable, but the second is essential in order > to ensure > > synchronization of the LSP database." > > > >And the third? If only for balance, you should say something about > >the third. > > How about rewording the next paragraph to read: > > "The third action above minimizes the number of LSPs which must be > exchanged and, if made reliable, provides a means of > determining when the > LSP databases of the neighboring routers have been > synchronized. This is > desirable whether the router is being restarted or not. This document > describes modifications to achieve this." Now I'm not sure what the last sentence refers to. > >Does this also belong in the overview, as an assumption? > > Ummm...errrr....it IS in the overview. Do you want it in the > Abstract?? Or Fine as is. > > "An instance of T1 is maintained per interface, and indicates the > > time after which an unacknowledged (re)start attempt will be > > repeated." > > > >It is not clear to me what an "unacknowledged restart attempt" is. > >I assume this is sending out the hello packets with the special > >TLV, but it could be read to include (re)setting the timers. > > If we reversed the order of the sub-sections: > 4.1 Timers > 4.2 Restart TLV > > so that the description of the use of the SA bit came before > the timers section would that clarify things for you? I'm honestly confused about what the timers do: some of this is the different roles in the starting and restarting cases, and some is not fully understanding the interactions. I can try rereading in that order to see if it makes things clearer. > >We can expect one of at least two policies from the Samaritans: a > >fixed time, and the remaining time left on the adjacency. Any > >suggestions on policies, or time required for a reboot? Is this > >a configuration parameter? A MIB parameter? > > The only "option" that the Helper router has here is > described in 4.2.1: > > a) The state of the adjacency is not changed. It is an > implementation choice whether or not the holding time of the > adjacency is refreshed. Not refreshing the holding time > preserves > the intention of the original holding time. Refreshing it may > allow a longer grace period for the completion of the (re)start > process. Whichever option is chosen, the "remaining time" > transmitted according to (b) below MUST reflect the actual time > after which the adjacency will now expire. Thanks > There has been some discussion that the Helper router should > be required to > accept the hold time in an IIH with RR set so as to allow the > restarting > router to get the time that it thinks it needs to complete > restart. The > danger is that a router which continually restarts without > ever completing > the restart procedure could cause the Helper router to maintain the > adjacency to the continually restarting router past the point of > reasonableness. There are some simple strategies to avoid this. I guess I would vote for simplicity right not. > >Do we need to think about versioning? > > [No] > > "b) immediately (i.e. without waiting for any currently > running timer > > interval to expire, but with a small random delay of a > few 10s of > > milliseconds on LANs to avoid "storms"), transmit over the > > corresponding interface an IIH including the restart > TLV with the > > RR bit clear and the RA bit set, having updated the "Point-to- > > Point Adjacency State" option to reflect any new > values received > > from the (re)starting router." > > > >Any new values? I presume this only means the link ID. > > In text preceding item b) we say: > > " ...if there exists on this interface an adjacency in state > "Up" with the > same System ID, and in the case > of a LAN circuit, with the same source LAN address" but the text above is about p2p circuits, no? > "Otherwise (i.e. if there was no adjacency in the "UP" state > to the system > ID in question), process the IIH as normal by reinitializing > the adjacency, and setting the RA bit in the returned IIH." My comment was simply that this was a discussion about how to deal with a p2p TLV from a restarting router. The original text mentions "any new values", while I think that there is only one new value, the restarter's Link Id, that we would actually take. > > "T3 is set to the minimum of its current value and the > value of the" > > > >Consider > > > > "The global timer T3 is set ..." > > In 4.1 we say: > > "A single instance of T3 is maintained for the entire system." > > Not clear why we would need the term "global". When I started writing technical docs, it was mathematics, and one rule I learned was "never start a sentence with a variable name." It seems to make things read better. Drop "global", and keep "The timer". I would have used a more descriptive term for T3 if I had it: global was just a verbal twitch. > >page 8 > > > >4.3.2 Adjacency acquisition during start > > > > The starting router wants to ensure that in the event a > neighboring > > > >Suggest you start the section with something to suggest the > transition. > > > > "Next we turn to the case of a router starting, without assuming > > any prior adjacencies." > > Is the sub section title not sufficient?? The first couple of times I read this, I thought the sections were duplicated by mistake. The prose suggested just moves the reader into your mindset. Again, this gets back to the similarity between "start" and "restart" - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 12:57:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20937 for ; Fri, 2 May 2003 12:57:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42H25806553; Fri, 2 May 2003 13:02:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42H1M806502 for ; Fri, 2 May 2003 13:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20771 for ; Fri, 2 May 2003 12:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bdpg-0005k1-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:56:24 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19Bdpa-0005gL-00 for isis-wg@ietf.org; Fri, 02 May 2003 12:56:18 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h42GEQxI002037; Fri, 2 May 2003 09:14:26 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-1052.cisco.com [10.21.100.28]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFV99469; Fri, 2 May 2003 09:07:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20030502090105.00ba0550@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 09:11:49 -0700 Jeff - Thanks for your thoughtful review. Please see my responses inline. Les At 05:16 PM 5/1/2003 -0400, Jeff Parker wrote: >The biggest request is for a FSM describing the state transitions >for the starting router and it's helpers. The comments below are >for clarity: I don't think I understand the protocol well enough >to comment. An earlier version of the draft had an FSM. It was removed based on feedback. (Hard to please everyone I guess.) We will consider adding it back in. >Indented text is quote from draft or proposed alternative. >Outdented text is commentary. > >page 1 > "This is necessary in order to invoke the protocol > mechanisms to ensure correct synchronization of the LSP database." > >But you go on to demonstrate that it -isn't- necessary. How about: "This invokes the protocol mechanisms which ensure correct synchronization of the LSP database." >page 2 > "This draft additionally describes a mechanism to optimize database > synchronization and minimize transient routing disruption when a > router starts." > >I'd suggest something to flag the difference between this and the >restarting case, as this is the first time this is encountered. >Perhaps replace the last line of the three above with > > "router starts without wishing to reuse prior adjacencies." The terms "restart/restarting","start/starting", and "(re)start/(re)starting" are very carefully defined so as to try to avoid confusion. (I like these better than "Phoenix", etc.) But the definitions occur AFTER the Abstract, which makes this first usage ambiguous. I am thinking we need to make the ABSTRACT much shorter and then use much of the current abstract as an introduction AFTER the terms have been defined. > "Firstly, when a routing process restarts and an adjacency to a > neighboring router is reinitialized the neighboring routing process > does three things:" > >The point of view changes from that of the restarting router to >the peer. Something like the following keeps in focused in place > > "When a router's peer restarts and the peer adjacency > is reinitialized, the router does three things:" How about: "When an adjacency is reinitialised as a result of a neighbor restating, the router does 3 things:". >This issue appears in other places. I think it would be helpful >to introduce terminology to describe three or four entities: > The restarting router > Could be split into starting router and restarting router I was hoping the terms defined in the "Conventions" section would be both clear and sufficient. > An aware and helpful peer > I don't recall needing an aware and unwilling peer > > A peer who is not aware of the protocol Not sure there is enough justification for using names for these cases, but I'll review the text and see. "Helper" certainly is good. Not sure about the "unaware". >The names could be fanciful (Phoenix, Newborn, Samaratin, and Innocent) >or more prosaic: Restarter, Rebooter, Helper, and Bystander. > > >Page 3 > "1. It reinitializes the adjacency and causes its own LSP(s) to be > regenerated, thus triggering SPF runs throughout the area (or > in the case of Level 2, throughout the domain). > > 2. It sets SRMflags on its own LSP database on the adjacency > concerned. > > 3. In the case of a Point-to-Point link it transmits a (set of) > CSNP(s) over the adjacency. > > In the case of a restarting router process, the first of these is > highly undesirable, but the second is essential in order to ensure > synchronization of the LSP database." > >And the third? If only for balance, you should say something about >the third. How about rewording the next paragraph to read: "The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not. This document describes modifications to achieve this." > "It is assumed that the three-way handshake [5] is being used on > Point-to-Point circuits." > >Does this also belong in the overview, as an assumption? Ummm...errrr....it IS in the overview. Do you want it in the Abstract?? Or ...??? > "An instance of T1 is maintained per interface, and indicates the > time after which an unacknowledged (re)start attempt will be > repeated." > >It is not clear to me what an "unacknowledged restart attempt" is. >I assume this is sending out the hello packets with the special >TLV, but it could be read to include (re)setting the timers. If we reversed the order of the sub-sections: 4.1 Timers 4.2 Restart TLV so that the description of the use of the SA bit came before the timers section would that clarify things for you? > "A single instance of T3 is maintained for the entire system. It > indicates the time after which the router will declare that it has > failed to achieve database synchronization (by setting the overload > bit in its own LSP). This is initialized to 65535 seconds, but is > set to the minimum of the remaining times of received IIHs > containing a restart TLV with RA set." > >We can expect one of at least two policies from the Samaritans: a >fixed time, and the remaining time left on the adjacency. Any >suggestions on policies, or time required for a reboot? Is this >a configuration parameter? A MIB parameter? The only "option" that the Helper router has here is described in 4.2.1: a) The state of the adjacency is not changed. It is an implementation choice whether or not the holding time of the adjacency is refreshed. Not refreshing the holding time preserves the intention of the original holding time. Refreshing it may allow a longer grace period for the completion of the (re)start process. Whichever option is chosen, the "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. There has been some discussion that the Helper router should be required to accept the hold time in an IIH with RR set so as to allow the restarting router to get the time that it thinks it needs to complete restart. The danger is that a router which continually restarts without ever completing the restart procedure could cause the Helper router to maintain the adjacency to the continually restarting router past the point of reasonableness. There are some simple strategies to avoid this. >page 4 > "Type 211 > Length 3 > Value (3 octets) > Flags (1 octet) > Bit 1 - Restart Request (RR) > Bit 2 - Restart Acknowledgment (RA) > Bit 3 - Suppress adjacency advertisement(SA) > Bits 4-8 - Reserved > Remaining Time (2 octets) > Remaining holding time (in seconds) > (note: only required when RA bit is set)" > >Do we need to think about versioning? We -can- always append more >fields. Inserting versions into TLVs has been discussed in the past in other contexts and rejected. It also seems possible to add things to the TLV in a backwards compatible way. The three way TLV managed to do that - though it did cause some confusion for the uninformed. > "b) immediately (i.e. without waiting for any currently running timer > interval to expire, but with a small random delay of a few 10s of > milliseconds on LANs to avoid "storms"), transmit over the > corresponding interface an IIH including the restart TLV with the > RR bit clear and the RA bit set, having updated the "Point-to- > Point Adjacency State" option to reflect any new values received > from the (re)starting router." > >Any new values? I presume this only means the link ID. System ID should >not change (if it does, the restart won't work) we should not restate our >Link ID, and this does not apply to the 3way state field. Marking what >you are looking for explicit will clear up questions. In text preceding item b) we say: " ...if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address" so the matching System ID requirement has been specified. We go on to say: "Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH." >Page 5 > "Both restarting and starting routers will make use of the RR bit in > the restart TLV, though at different stages of the (re)start > procedure." > >I found this a bit easier to read > > "Restarting and starting routers will make use of the RR bit in > the restart TLV, though each will use them at different stages > of the (re)start procedure." OK. >page 6 > "On receipt of an IIH by the restarting router, a local adjacency is..." > >Consider > > "When a restarting router receives an IIH, a local adjacency is..." OK > "T3 is set to the minimum of its current value and the value of the" > >Consider > > "The global timer T3 is set ..." In 4.1 we say: "A single instance of T3 is maintained for the entire system." Not clear why we would need the term "global". >page 7 > "When BOTH a complete set of CSNP(s) (for each active level, in the > case of a pt-pt circuit) and an acknowledgement have been received > over the interface, the timer T1 is cancelled." > >And then what happens? We don't send IIH with RR bit set? We start >the SPF? Perhaps a FSM for restart and Samaritan would help. No further action is taken as a result of T1 cancellation. It is T2/T3 cancellation/expiration which is required for further action. >page 8 > >4.3.2 Adjacency acquisition during start > > The starting router wants to ensure that in the event a neighboring > >Suggest you start the section with something to suggest the transition. > > "Next we turn to the case of a router starting, without assuming > any prior adjacencies." Is the sub section title not sufficient?? >- jeff parker >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 13:29:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21848 for ; Fri, 2 May 2003 13:29:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HY8808998; Fri, 2 May 2003 13:34:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HXX808962 for ; Fri, 2 May 2003 13:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21720 for ; Fri, 2 May 2003 13:26:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeKl-0005uY-00 for isis-wg@ietf.org; Fri, 02 May 2003 13:28:31 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19BeKP-0005uM-00 for isis-wg@ietf.org; Fri, 02 May 2003 13:28:10 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h42HRTua004041; Fri, 2 May 2003 10:27:29 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-1052.cisco.com [10.21.100.28]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW05484; Fri, 2 May 2003 10:20:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20030502095143.00b8b878@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 10:22:42 -0700 At 12:46 PM 5/2/2003 -0400, Jeff Parker wrote: > > > >I'd suggest something to flag the difference between this and the > > >restarting case, as this is the first time this is encountered. > > >Perhaps replace the last line of the three above with > > > > > > "router starts without wishing to reuse prior adjacencies." > > > > The terms "restart/restarting","start/starting", and > > "(re)start/(re)starting" are very carefully defined so as to > > try to avoid > > confusion. (I like these better than "Phoenix", etc.) But the > > definitions > > occur AFTER the Abstract, which makes this first usage > > ambiguous. I am > > thinking we need to make the ABSTRACT much shorter and then > > use much of the > > current abstract as an introduction AFTER the terms have been defined. > >There are two issues: the text in this case, which caught >me unprepared for the difference you were discussing >between start and restart, and the general case. This >case can be handled by flagging the difference. > >For the general case, I find starting and restarting very >close, and thus confusing. I agree that the terms are >carefully defined. I understand that the terms "start" and "restart" look a lot alike. However they do accurately capture what the router is doing. And we have tried to use them very carefully and consistently throughout the document. This seems like the best way to make the text as clear as possible. Although terms like "Phoenix" and "Newbie" are more colorful, my informal and unscientific survey says they are not very popular. (Translation: Neither Mike nor I like them) > > >The point of view changes from that of the restarting router to > > >the peer. Something like the following keeps in focused in place > > > > > > "When a router's peer restarts and the peer adjacency > > > is reinitialized, the router does three things:" > > > > How about: > > > > "When an adjacency is reinitialised as a result of a > > neighbor restating, the router does 3 things:". > >I think I know whose point of view we have here, but I'm >still not certain. Adding "router's" helps me. > > "When a router's adjacency is reinitialised as a result of a > neighbor restating, the router does 3 things:". > I think we are close enough to declare agreement. > > >Page 3 > > > "1. It reinitializes the adjacency and causes its own > > LSP(s) to be > > > regenerated, thus triggering SPF runs throughout > > the area (or > > > in the case of Level 2, throughout the domain). > > > > > > 2. It sets SRMflags on its own LSP database on the adjacency > > > concerned. > > > > > > 3. In the case of a Point-to-Point link it transmits a (set of) > > > CSNP(s) over the adjacency. > > > > > > In the case of a restarting router process, the first of these is > > > highly undesirable, but the second is essential in order > > to ensure > > > synchronization of the LSP database." > > > > > >And the third? If only for balance, you should say something about > > >the third. > > > > How about rewording the next paragraph to read: > > > > "The third action above minimizes the number of LSPs which must be > > exchanged and, if made reliable, provides a means of > > determining when the > > LSP databases of the neighboring routers have been > > synchronized. This is > > desirable whether the router is being restarted or not. This document > > describes modifications to achieve this." > >Now I'm not sure what the last sentence refers to. > Second attempt: "The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not. This document describes modifications to prevent undesirable adjacency reinitialization and to reliably determine when the LSP databases of neighboring routers have been synchronized." > > > "b) immediately (i.e. without waiting for any currently > > running timer > > > interval to expire, but with a small random delay of a > > few 10s of > > > milliseconds on LANs to avoid "storms"), transmit over the > > > corresponding interface an IIH including the restart > > TLV with the > > > RR bit clear and the RA bit set, having updated the "Point-to- > > > Point Adjacency State" option to reflect any new > > values received > > > from the (re)starting router." > > > > > >Any new values? I presume this only means the link ID. > > > > In text preceding item b) we say: > > > > " ...if there exists on this interface an adjacency in state > > "Up" with the > > same System ID, and in the case > > of a LAN circuit, with the same source LAN address" > >but the text above is about p2p circuits, no? No. It talks about both. Perhaps we need to say "in the case of Point-to-point adjacencies having updated the "Point-to- Point Adjacency State" option to reflect any new values received" Seems a bit redundant, but perhaps clearer. > > > "Otherwise (i.e. if there was no adjacency in the "UP" state > > to the system > > ID in question), process the IIH as normal by reinitializing > > the adjacency, and setting the RA bit in the returned IIH." > >My comment was simply that this was a discussion about how to >deal with a p2p TLV from a restarting router. The original >text mentions "any new values", while I think that there is >only one new value, the restarter's Link Id, that we would >actually take. Well, you are correct, but with the current text we are "future-proofed" should the 3-way TLV ever be extended to include additional information. >When I started writing technical docs, it was mathematics, >and one rule I learned was "never start a sentence with a >variable name." It seems to make things read better. >Drop "global", and keep "The timer". I would have used >a more descriptive term for T3 if I had it: global was >just a verbal twitch. Point taken. "The timer T3" is better. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 13:35:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22170 for ; Fri, 2 May 2003 13:35:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HdB810125; Fri, 2 May 2003 13:39:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HaL809082 for ; Fri, 2 May 2003 13:36:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21826 for ; Fri, 2 May 2003 13:29:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeNS-0005vL-00 for isis-wg@ietf.org; Fri, 02 May 2003 13:31:19 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19BeN8-0005v5-00 for isis-wg@ietf.org; Fri, 02 May 2003 13:30:58 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h42HUGxI021030; Fri, 2 May 2003 10:30:16 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-1052.cisco.com [10.21.100.28]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW05711; Fri, 2 May 2003 10:22:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20030502102817.03d0c960@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "DUBOIS Nicolas FTRD/DAC/ISS" From: Les Ginsberg Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Cc: "Jeff Parker" , "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 10:30:14 -0700 At 04:43 PM 5/2/2003 +0200, DUBOIS Nicolas FTRD/DAC/ISS wrote: >Even though it is out of the scope of this working group ... one other >thing we would support and find useful is a simple detection mechanism for >lost hellos (or expected hellos that do not come in the expected >timeframe) as this would help having finer granularity in the >approximation of link reliability at the IS-IS level. Having this >granularity would help us tell you wether we need graceful restart or not. > >Best regards, > >Nicolas Dubois >core packet network lab >France Telecom R&D Nicolas - Could you explain what you think the relationship between link reliability and graceful restart is? I am having trouble making the connection. Thanx. Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 2 14:48:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25269 for ; Fri, 2 May 2003 14:48:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42IqD815957; Fri, 2 May 2003 14:52:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Ipt815922 for ; Fri, 2 May 2003 14:51:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25062; Fri, 2 May 2003 14:44:45 -0400 (EDT) Message-Id: <200305021844.OAA25062@ietf.org> To: IETF-Announce: ; Cc: isis-wg@ietf.org From: The IESG Reply-to: iesg@ietf.org Subject: [Isis-wg] Last Call: IS-IS Cryptographic Authentication to Informational Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 14:44:45 -0400 The IESG has received a request from the IS-IS for IP Internets Working Group to consider IS-IS Cryptographic Authentication as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-16. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-04.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat May 3 03:15:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25058 for ; Sat, 3 May 2003 03:15:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h437Kl815542; Sat, 3 May 2003 03:20:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h437J7815460 for ; Sat, 3 May 2003 03:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24971 for ; Sat, 3 May 2003 03:11:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BrDU-0002xL-00 for isis-wg@ietf.org; Sat, 03 May 2003 03:13:52 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with smtp (Exim 4.12) id 19BrDO-0002x2-00 for isis-wg@ietf.org; Sat, 03 May 2003 03:13:46 -0400 Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Sat, 03 May 2003 09:13:47 +0200 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 3 May 2003 09:13:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Message-ID: Thread-Topic: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Thread-Index: AcMQ0LNqxpUPTkpJTpqX873QD73WtgAb/Mjw From: "DUBOIS Nicolas FTRD/DAC/ISS" To: "Les Ginsberg" Cc: "ISIS-WG (E-mail)" X-OriginalArrivalTime: 03 May 2003 07:13:17.0033 (UTC) FILETIME=[78012D90:01C31143] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h437J7815461 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 May 2003 09:13:16 +0200 Content-Transfer-Encoding: 8bit Lee, Maybe it is a misunderstanding from our side : To summarize my understanding was that Graceful restart would help in case there is a problem at the ISIS level (control plane in our terminology) , but not at the below level (forwarding plane in our terminology that is interface and sonet level). So in our current network (with almost no graceful restart implemented) we tried to gather statistics that would match with following conditions (that should theoretically not exist): "ISIS problem + Sonet OK + Interface OK" Results are: This occurs quite often: In case of minor congestion on a link, it happens that once upon a while an adjacency fails, whereas the link stays up from the other indicators point of view ( no Sonet problems / no interface crash problem) (in fact it behaves as if it were dropping aleatory hellos, and at some point 3 consecutive hellos are dropped). In case of severe congestion on a link, it always happens that the adjacency flaps a lot, whereas sonet and interface stay up (at least in the log we have, maybe we are missing some logs) Our understanding was that the two above phenomenon would interfere with graceful restart, and that instead of having a simple usual congestion panic (on the 2000 ISIS links we have, it happens once a week on average), we would have a graceful congestion panic which is not particularly desirable.We do not think graceful restart is the adequate answer to this problem and we would prefer to address this problem in another way. Can you tell me whether graceful restart would trigger in the above described flapping situations ? I must admit I didn't read the latest version of the draft and that the latest tests I have done on the subject are at least 6 months old, so I might be confused. Best regards, Nicolas -----Message d'origine----- De : Les Ginsberg [mailto:ginsberg@cisco.com] Envoye : vendredi 2 mai 2003 19:30 A : DUBOIS Nicolas FTRD/DAC/ISS Cc : Jeff Parker; ISIS-WG (E-mail) Objet : RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt At 04:43 PM 5/2/2003 +0200, DUBOIS Nicolas FTRD/DAC/ISS wrote: >Even though it is out of the scope of this working group ... one other >thing we would support and find useful is a simple detection mechanism for >lost hellos (or expected hellos that do not come in the expected >timeframe) as this would help having finer granularity in the >approximation of link reliability at the IS-IS level. Having this >granularity would help us tell you wether we need graceful restart or not. > >Best regards, > >Nicolas Dubois >core packet network lab >France Telecom R&D Nicolas - Could you explain what you think the relationship between link reliability and graceful restart is? I am having trouble making the connection. Thanx. Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat May 3 17:16:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09138 for ; Sat, 3 May 2003 17:16:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h43LKi809487; Sat, 3 May 2003 17:20:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h43LIq809405 for ; Sat, 3 May 2003 17:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09071 for ; Sat, 3 May 2003 17:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C4Jm-0006E5-00 for isis-wg@ietf.org; Sat, 03 May 2003 17:13:14 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19C4JS-0006Dd-00 for isis-wg@ietf.org; Sat, 03 May 2003 17:12:54 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h43L8Rua023357; Sat, 3 May 2003 14:08:27 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-506.cisco.com [10.21.81.250]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW63188; Sat, 3 May 2003 14:00:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20030503134531.00b9a578@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "DUBOIS Nicolas FTRD/DAC/ISS" From: Les Ginsberg Subject: RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 03 May 2003 14:08:25 -0700 Nicolas - Graceful restart is not applicable to your situation. Graceful restart is targeted at two situations: 1)Where the control plane restarts and the forwarding plane is maintained. In this case (referred to as "restarting" in the draft) the protocol enhancements described in the draft try to eliminate unnecessary adjacency flapping and the associated temporary network instability. An example case where this might be used is when a software upgrade is performed on the control plane software in a router in which it is possible to maintain the forwarding plane state across the software upgrade. 2)Where the control plane restarts and the forwarding plane is not maintained. In this case (referred to as "starting" in the draft) the protocol enhancements described in the draft try to eliminate temporary blackholes caused by the presence in the network of stale LSPs issued by the router which has just started. An example case where this might be used is an ordinary reboot of a router. In both cases the protocol extensions allow the router which has restarted/started to reliably determine when its LSP database is synced with its neighbors. In the case you discuss below, the control plane operational state never changes - it is always up - but for other reasons adjacencies are flapping. The restart draft is not applicable to this case. Les At 09:13 AM 5/3/2003 +0200, DUBOIS Nicolas FTRD/DAC/ISS wrote: >Lee, > > > >Maybe it is a misunderstanding from our side : > >To summarize my understanding was that Graceful restart would help in >case there is a problem at the ISIS level (control plane in our >terminology) , but not at the below level (forwarding plane in our >terminology that is interface and sonet level). > >So in our current network (with almost no graceful restart implemented) >we tried to gather statistics that would match with following conditions >(that should theoretically not exist): >"ISIS problem + Sonet OK + Interface OK" > >Results are: >This occurs quite often: > In case of minor congestion on a link, it happens that once upon >a while an adjacency fails, whereas the link stays up from the other >indicators point of view ( no Sonet problems / no interface crash >problem) (in fact it behaves as if it were dropping aleatory hellos, and >at some point 3 consecutive hellos are dropped). > In case of severe congestion on a link, it always happens that >the adjacency flaps a lot, whereas sonet and interface stay up (at least >in the log we have, maybe we are missing some logs) > > >Our understanding was that the two above phenomenon would interfere with >graceful restart, and that instead of having a simple usual congestion >panic (on the 2000 ISIS links we have, it happens once a week on >average), we would have a graceful congestion panic which is not >particularly desirable.We do not think graceful restart is the adequate >answer to this problem and we would prefer to address this problem in >another way. > >Can you tell me whether graceful restart would trigger in the above >described flapping situations ? > >I must admit I didn't read the latest version of the draft and that the >latest tests I have done on the subject are at least 6 months old, so I >might be confused. > > >Best regards, > >Nicolas > >-----Message d'origine----- >De : Les Ginsberg [mailto:ginsberg@cisco.com] >Envoye : vendredi 2 mai 2003 19:30 >A : DUBOIS Nicolas FTRD/DAC/ISS >Cc : Jeff Parker; ISIS-WG (E-mail) >Objet : RE: [Isis-wg] Notes on draft-ietf-isis-restart-03.txt > > >At 04:43 PM 5/2/2003 +0200, DUBOIS Nicolas FTRD/DAC/ISS wrote: > >Even though it is out of the scope of this working group ... one other > >thing we would support and find useful is a simple detection mechanism >for > >lost hellos (or expected hellos that do not come in the expected > >timeframe) as this would help having finer granularity in the > >approximation of link reliability at the IS-IS level. Having this > >granularity would help us tell you wether we need graceful restart or >not. > > > >Best regards, > > > >Nicolas Dubois > >core packet network lab > >France Telecom R&D > >Nicolas - > >Could you explain what you think the relationship between link >reliability >and graceful restart is? I am having trouble making the connection. > >Thanx. > > Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 5 19:59:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21907 for ; Mon, 5 May 2003 19:59:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4604f815112; Mon, 5 May 2003 20:04:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4603l815082 for ; Mon, 5 May 2003 20:03:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21868 for ; Mon, 5 May 2003 19:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CppW-0001zf-00 for isis-wg@ietf.org; Mon, 05 May 2003 19:57:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19CppQ-0001zc-00 for isis-wg@ietf.org; Mon, 05 May 2003 19:57:04 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Cpq3-000Izc-00; Mon, 05 May 2003 23:57:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <121178557311.20030505165323@psg.com> To: isis-wg@ietf.org CC: Les Ginsberg In-Reply-To: <4.3.2.7.2.20030502091700.00b87580@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20030502091700.00b87580@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Obsoleting RFC1142 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 May 2003 16:53:23 -0700 Content-Transfer-Encoding: 7bit Les, Wrt RFC1142, I did check with JTC1 guys and they do not mind us publish the latest version of the standard as an INFO IETF RFC. If we did, the new publication would obsolete 1142. Micah was planning to start running with this in April, by the way ;-) If the new RFC takes long or doesn't get published, we can move 1142 to Historic (the way of saying it's obsolete.) -- Alex http://www.psg.com/~zinin/ Friday, May 2, 2003, 9:28:51 AM, Les Ginsberg wrote: > The above two drafts reference RFC 1142. They should not. > RFC 1142 was published in 1990 based on an early draft of what eventually > became ISO 10589:1992. As such, it contains a number of defects which were > corrected prior to the publication of the 1992 ISO standard. Because of > this it should NOT be used as a reference for the protocol. > As I recall, a number of questions have been brought to this list over the > years because some folks thought that RFC 1142 was a legitimate reference > and rediscovered defects which had long ago been corrected. It would be a > good thing if RFC 1142 was moved to OBSOLETE status. > In any case, drafts should not reference this RFC. > Now that the second edition of ISO 10589 is an official standard, it would > also be good if drafts referenced the newer version: > "ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:2002, Second Edition." > Les > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 5 20:38:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22733 for ; Mon, 5 May 2003 20:38:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460j9818490; Mon, 5 May 2003 20:45:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h460io818467 for ; Mon, 5 May 2003 20:44:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22673 for ; Mon, 5 May 2003 20:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CqTE-0002Bs-00 for isis-wg@ietf.org; Mon, 05 May 2003 20:38:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19CqT8-0002Bo-00 for isis-wg@ietf.org; Mon, 05 May 2003 20:38:06 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19CqTl-000Lrp-00; Tue, 06 May 2003 00:38:45 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <165181004120.20030505173410@psg.com> To: isis-wg@ietf.org CC: Acee Lindem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 May 2003 17:34:10 -0700 Content-Transfer-Encoding: 7bit Folks- I reviewed the draft and had an opportunity to discuss my comments with the authors and the WG chairs. Below is the summary. I also include comments from the rtg-dir--thanks, Acee. Meta: Why do we need two tag TLVs? This is still an open question for me. Clearly, one 32-bit tag is enough to control prefix distribution throughout the domain. Two tags complicate both the specification and operation of the network, as we have to deal with some "interesting" questions, like whether the implementations should be able act upon (filter prefixes based on) just one TLV or both, and whether the two TLVs operate on the same (64-bit) value space (with one covering only 1/2) or on separate ones, and how they should work together. So, I studied the ML archives looking for clue and I found that the main motivation for the 64-bit tag appears to be transporting of Extended Communities for a certain case of 2547 deployment. If that's the case, than it seems that a better approach would be to specify the 64-bit TLV as a "BGP " or "VPN " and be honest about it's functionality than to have two tags. I'd love to hear more on this topic. We had an agreement on the rest of the issues below. 1. Discourage incompatible intra-area SPF modifications There is a case where one could potentially use a tag value to decide to not install a prefix in the routing table during intra-area RT calculation and get into loops or blackholes. Some words should be put in the text saying that implementations should not use tags to change their intra-area routing calculation in a way that would make it inconsistent with ISO 10589. 2. Require compliant implementations to support prefix filtering at area borders The draft definitely reads like filtering at the area boundaries is one of the major applications of this TLV. However, because the document requests the compliant implementations to only be able to insert the tag, but not filter using it at the L1/L2 IS'es, an operator cannot expect all compliant implementations to be useful for this function, i.e., they will need to ask if functions outside the scope of this document are supported by specific vendors, go into details of how they do that to make sure different implementations can work together in a consistent way. Putting in 'MUST support filtering at the area boundaries' would solve this. 3. Processing of multiple instances of the TLV. I could see some implementations deciding to merge the tag sets, and some using just the first (or the last) instance, which would result in interop issues. We need consistency in behavior. The proposal was to put text saying that only the first copy of the TLV must be considered. 4. Tag ordering clarifications Text in section 6 needs to be clarified to make it explicit that [re]ordering of tags makes sense only when L1/L2 route leaking is performed. 5. IANA considerations Change the text to say "This document defines..." 6. Comments from rtg-dir: > 1. The last sentence of the abstract doesn't make sense. "Additionally, > the information can be placed in LSPs that have TLVs as yet > undefined, if this information is used to convey the same > meaning in these future TLVs as it used in the currently defined > TLVs". Suggested - "The administrative tag sub-TLVs may be used with > with future TLVs as long as their semantics are preserved." > > 2. Section 5.2 - The value of the type is wrong - it should be 2 rather > than 1. > > 3. Section 6 says the ordering of tags is not significant. However, the > previous sections (5.1 and 5.2) say that an implementation may only > consider the first tag. > > 4. Section 7 - List the requirements for receiving the new Sub-TLVs in > this compliance section as well (even if they were stated previously). > > 5. Section 8 - The example talks about R2 associating tag 110 with property > A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with property > A is adjacent to R1 (which applies to me that R1 originate the prefix). > Please fix either the example or the figure. Nits below: > 1. Status of this Memo Shouldn't be numbered > 2. Abstract The rfc-ed will not like the references in the abstract, please remove. > 5.1. 32-bit Administrative Tag Sub-TLV 1 > > The Administrative Tag shall be encoded as one or more 4 octet > unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The > Administrative Tag Sub-TLV has following structure: > > 1 octet of type (value: 1) > 1 octet of length (value: multiple of 4) > one or more instances of 4 octets of administrative tag Would be great if we had the same format as in RFC1195, or 3373 for consistency. Using IETF format is an option too. Ditto for 5.2 > 12. References Please split them to normative and informative like below: 12. Normative References [1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", Internet Draft, "Work in Progress", September 2000. [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution with Two-Level IS-IS" RFC 2966, October 2000 13. Informative References [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999. [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 2002. Nits from Acee: > 1. The abstract contains references. The documents should be specified > by name since the abstract can be excerpted. > > 2. Line 323 over 72 chars. > > Line 323 length is 74 > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > > 3. Pages 2, 3, 4, and 5 have over 58 lines. Thanks! -- Alex Zinin _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 6 17:05:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09059 for ; Tue, 6 May 2003 17:05:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46L6w828959; Tue, 6 May 2003 17:06:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46L5l828870 for ; Tue, 6 May 2003 17:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08698 for ; Tue, 6 May 2003 16:56:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D9WN-0002Qs-00 for isis-wg@ietf.org; Tue, 06 May 2003 16:58:43 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19D9WM-0002Q0-00 for isis-wg@ietf.org; Tue, 06 May 2003 16:58:42 -0400 Received: from cisco.com (sjc-vpn1-334.cisco.com [10.21.97.78]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h46Kx0ua029340; Tue, 6 May 2003 13:59:01 -0700 (PDT) Subject: Re: [Isis-wg] Obsoleting RFC1142 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: isis-wg@ietf.org, Les Ginsberg To: Alex Zinin From: Micah Bartell In-Reply-To: <121178557311.20030505165323@psg.com> Message-Id: <93F1A344-8005-11D7-9E42-000A95765246@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 May 2003 15:59:07 -0500 Content-Transfer-Encoding: 7bit Alex, The work is already in progress. /mpb On Monday, May 5, 2003, at 18:53 US/Central, Alex Zinin wrote: > Les, > > Wrt RFC1142, I did check with JTC1 guys and they do not mind us > publish the latest version of the standard as an INFO IETF RFC. > If we did, the new publication would obsolete 1142. Micah was > planning to start running with this in April, by the way ;-) > > If the new RFC takes long or doesn't get published, we can move > 1142 to Historic (the way of saying it's obsolete.) > > -- > Alex > http://www.psg.com/~zinin/ > > Friday, May 2, 2003, 9:28:51 AM, Les Ginsberg wrote: >> The above two drafts reference RFC 1142. They should not. > >> RFC 1142 was published in 1990 based on an early draft of what >> eventually >> became ISO 10589:1992. As such, it contains a number of defects which >> were >> corrected prior to the publication of the 1992 ISO standard. Because >> of >> this it should NOT be used as a reference for the protocol. > >> As I recall, a number of questions have been brought to this list >> over the >> years because some folks thought that RFC 1142 was a legitimate >> reference >> and rediscovered defects which had long ago been corrected. It would >> be a >> good thing if RFC 1142 was moved to OBSOLETE status. > >> In any case, drafts should not reference this RFC. > >> Now that the second edition of ISO 10589 is an official standard, it >> would >> also be good if drafts referenced the newer version: > >> "ISO, "Intermediate system to Intermediate system routeing >> information exchange protocol for use in conjunction with the >> Protocol for providing the Connectionless-mode Network Service >> (ISO 8473)," ISO/IEC 10589:2002, Second Edition." > > >> Les > >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 00:56:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20646 for ; Wed, 7 May 2003 00:56:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4753k830835; Wed, 7 May 2003 01:03:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h474Xo828535 for ; Wed, 7 May 2003 00:33:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20048 for ; Wed, 7 May 2003 00:24:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DGVo-0004zr-00 for isis-wg@ietf.org; Wed, 07 May 2003 00:26:36 -0400 Received: from [64.219.248.6] (helo=mailhost.metro-optix.com) by ietf-mx with esmtp (Exim 4.12) id 19DGVo-0004zn-00 for isis-wg@ietf.org; Wed, 07 May 2003 00:26:36 -0400 Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 May 2003 23:22:17 -0500 Message-ID: <99EC34181384D611BE56000347227B2C1932E8@MAILHOSTNB> From: Sumesh K P To: "'isis-wg@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] clns static routes exporting to is-is Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 May 2003 23:20:54 -0500 Hi All, See the topology below. + --------+ +----------+ +----------+ | A | <-----------> | B | <----------->| C | +---------+ +----------+ +----------+ Case - 1 ------------- A is an ES and does not run ES-IS B and C are ISs and runs IS-IS in dual-mode. Static clnp ES route to A is configured at B. Should this ES information be carried in B's ES neighbor TLV ?. Case - 2 ------------- A is an IS and does not run IS-IS. B and C are ISs and runs IS-IS in dual-mode. Static clnp IS route to A is configured at B. Should this IS information be carried in B's IS neighbor TLV ?. Case-3 ----------- Is this applicable for IP based information too ?. Please reply with CC to sumeshkp@metro-optix.com. I am temporarily unsubscribed from this list due to some "unknown" problem, but Tony knows :). Thank You, Sumesh. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 01:00:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20862 for ; Wed, 7 May 2003 01:00:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47582831969; Wed, 7 May 2003 01:08:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4757N831501 for ; Wed, 7 May 2003 01:07:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20741 for ; Wed, 7 May 2003 00:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DH2G-00059v-00 for isis-wg@ietf.org; Wed, 07 May 2003 01:00:08 -0400 Received: from [64.219.248.6] (helo=mailhost.metro-optix.com) by ietf-mx with esmtp (Exim 4.12) id 19DH2G-00059s-00 for isis-wg@ietf.org; Wed, 07 May 2003 01:00:08 -0400 Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 May 2003 23:56:08 -0500 Message-ID: <99EC34181384D611BE56000347227B2C1932EC@MAILHOSTNB> From: Sumesh K P To: "'isis-wg@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] clns static routes exporting to is-is Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 May 2003 23:54:37 -0500 > Hi All, > > See the topology below. > > + --------+ +----------+ +----------+ > | A | <-----------> | B | <----------->| C | > +---------+ +----------+ +----------+ > > Case - 1 > ------------- > A is an ES and does not run ES-IS > B and C are ISs and runs IS-IS in dual-mode. > Static clnp ES route to A is configured at B. > Should this ES information be carried in B's ES neighbor TLV ?. > > Case - 2 > ------------- > A is an IS and does not run IS-IS. > B and C are ISs and runs IS-IS in dual-mode. > Static clnp IS route to A is configured at B. > Should this IS information be carried in B's IS neighbor TLV ?. > > Case-3 > ----------- > Is this applicable for IP based information too ?. > > Please reply with CC to sumeshkp@metro-optix.com. I am temporarily > unsubscribed from this list due to some "unknown" problem, but Tony knows > :). > > Thank You, > Sumesh. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 02:44:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18306 for ; Wed, 7 May 2003 02:44:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476nI816928; Wed, 7 May 2003 02:49:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h476k6816846 for ; Wed, 7 May 2003 02:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18164 for ; Wed, 7 May 2003 02:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DIZl-0005py-00 for isis-wg@ietf.org; Wed, 07 May 2003 02:38:49 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19DIZk-0005pv-00 for isis-wg@ietf.org; Wed, 07 May 2003 02:38:48 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h476dbsI004018 for ; Tue, 6 May 2003 23:39:37 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h476dYir013298 for ; Wed, 7 May 2003 01:39:35 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 02:39:23 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Sumesh K P'" , isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 02:41:04 -0400 Sumesh & all, My 2 cents. Please correct me if I misinterpret. >Case - 1 >------------- >A is an ES and does not run ES-IS >B and C are ISs and runs IS-IS in dual-mode. >Static clnp ES route to A is configured at B. >Should this ES information be carried in B's ES neighbor TLV ?. I think you are right. You advertise them in ES neighbor TLV so that it will be treated as the leaf node. >Case - 2 >------------- >A is an IS and does not run IS-IS. >B and C are ISs and runs IS-IS in dual-mode. >Static clnp IS route to A is configured at B. >Should this IS information be carried in B's IS neighbor TLV ?. You claim that A is an IS. In the topology, though it is not connected to any other ISs. If that is the case, I think it doesn't really matter if you advertise it in ES neighbor TLV (or) IS neighbor TLV because anyway it is a leaf node. On contrary, if A is connected to other ISs (hope fully running IS-IS protocol among them and obviously it has got some LSPs). In this case, you CAN choose to advertise it in IS neighbor TLV since it has got some network topology to be considered in SPF. >Case-3 >----------- >Is this applicable for IP based information too ?. Since the info. is static, you advertise it in IP external reachability info. Correct me if I'm wrong. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 02:59:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18507 for ; Wed, 7 May 2003 02:59:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47766817623; Wed, 7 May 2003 03:06:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4775i817597 for ; Wed, 7 May 2003 03:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18439 for ; Wed, 7 May 2003 02:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DIsl-0005tu-00 for isis-wg@ietf.org; Wed, 07 May 2003 02:58:27 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19DIsk-0005tr-00 for isis-wg@ietf.org; Wed, 07 May 2003 02:58:26 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h476xIsI011749 for ; Tue, 6 May 2003 23:59:18 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h476xGQx004432 for ; Wed, 7 May 2003 01:59:17 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 02:59:04 -0400 Message-ID: From: "Jonnala, Nagi" To: "Jonnala, Nagi" , "'Sumesh K P'" , isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 03:00:59 -0400 >>Case - 2 >>------------- >>A is an IS and does not run IS-IS. >>B and C are ISs and runs IS-IS in dual-mode. >>Static clnp IS route to A is configured at B. >>Should this IS information be carried in B's IS neighbor TLV ?. >You claim that A is an IS. In the topology, though it is not >connected to any other ISs. If that is the case, I think it doesn't >really matter if you advertise it in ES neighbor TLV (or) IS neighbor TLV >because anyway it is a leaf node. >On contrary, if A is connected to other ISs (hope fully running IS-IS >protocol among them and obviously it has got some LSPs). >In this case, you CAN choose to advertise it in IS neighbor TLV >since it has got some network topology to be considered in SPF. I'm wrong. You should always advertise it in ES neighbor TLV but never in IS neighbors TLV. The reason is that it might create lot of issues if you advertise it in IS neighbor TLV and the link is down for some reason and you never know it is down since it is a static route. Thanks to Vishwas for the offline discussion. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 03:20:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19010 for ; Wed, 7 May 2003 03:20:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h477R8819400; Wed, 7 May 2003 03:27:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h477QO819365 for ; Wed, 7 May 2003 03:26:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18932 for ; Wed, 7 May 2003 03:17:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DJCl-00061n-00 for isis-wg@ietf.org; Wed, 07 May 2003 03:19:07 -0400 Received: from [64.219.248.6] (helo=mailhost.metro-optix.com) by ietf-mx with esmtp (Exim 4.12) id 19DJCk-00061k-00 for isis-wg@ietf.org; Wed, 07 May 2003 03:19:06 -0400 Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 02:15:07 -0500 Message-ID: <99EC34181384D611BE56000347227B2C1932EF@MAILHOSTNB> From: Sumesh K P To: "'Jonnala, Nagi'" , isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 02:13:33 -0500 Hi Nagi et. al, Thank You very much for the reply. You interpreted the mail right. Let us take this ring-case, all of them runs IS-IS. A, B and C runs IS-IS on both the interfaces while the interface of D connected to C is a passive interface. A static route to D is configured at C. In this case should C be advertising this to B in its IS neighbor TLV or the ES-neighbor TLV ?. I am not sure how A will be interpreting D received from B's LSP, in case the information is carried in the ES neighbor TLV. +-----+ +-----+ | A |<------>| B | +-----+ +-----+ A A | | V V +-----+ +-----+ | D |<------>| C | +-----+ +-----+ Regards, Sumesh. Original Message----- From: Jonnala, Nagi [mailto:nagij@netplane.com] Sent: Wednesday, May 07, 2003 12:31 PM To: Jonnala, Nagi; 'Sumesh K P'; isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is >>Case - 2 >>------------- >>A is an IS and does not run IS-IS. >>B and C are ISs and runs IS-IS in dual-mode. >>Static clnp IS route to A is configured at B. >>Should this IS information be carried in B's IS neighbor TLV ?. >You claim that A is an IS. In the topology, though it is not >connected to any other ISs. If that is the case, I think it doesn't >really matter if you advertise it in ES neighbor TLV (or) IS neighbor TLV >because anyway it is a leaf node. >On contrary, if A is connected to other ISs (hope fully running IS-IS >protocol among them and obviously it has got some LSPs). >In this case, you CAN choose to advertise it in IS neighbor TLV >since it has got some network topology to be considered in SPF. I'm wrong. You should always advertise it in ES neighbor TLV but never in IS neighbors TLV. The reason is that it might create lot of issues if you advertise it in IS neighbor TLV and the link is down for some reason and you never know it is down since it is a static route. Thanks to Vishwas for the offline discussion. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 7 04:25:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20526 for ; Wed, 7 May 2003 04:25:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h478Vb824472; Wed, 7 May 2003 04:31:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h478A8823489 for ; Wed, 7 May 2003 04:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19961 for ; Wed, 7 May 2003 04:00:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DJt4-0006Ji-00 for isis-wg@ietf.org; Wed, 07 May 2003 04:02:50 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19DJt3-0006Jf-00 for isis-wg@ietf.org; Wed, 07 May 2003 04:02:49 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h4783fI2012212 for ; Wed, 7 May 2003 01:03:41 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h4783eQx009247 for ; Wed, 7 May 2003 03:03:40 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 04:03:28 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Sumesh K P'" , isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 04:05:16 -0400 Sumesh, The idea behind advertising D in ES neighbor TLV in C's LSP is: 1) If anybody wants to reach that particular destination D, no problems, you can use this information. 2) If you want to go "through" intermediate station D, sorry, you cannot use this information. Specific answer to your question is below. Let us assume 'X' is connected to D only. A interprets that ES neighbor TLV (regarding D) received through B like this. I can use this route to end station D(through B) if this path has low cost than the direct path to D. But A will not caluculate any route to X through A-B-C-D-X because the ES TLV says it is just a leaf node. Conversely, A can calculate a route to X through A-D-X because D is a neighbor to A. -Nagi. -----Original Message----- From: Sumesh K P [mailto:sumeshkp@metro-optix.com] Sent: Wednesday, May 07, 2003 12:44 PM To: 'Jonnala, Nagi'; isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is Hi Nagi et. al, Thank You very much for the reply. You interpreted the mail right. Let us take this ring-case, all of them runs IS-IS. A, B and C runs IS-IS on both the interfaces while the interface of D connected to C is a passive interface. A static route to D is configured at C. In this case should C be advertising this to B in its IS neighbor TLV or the ES-neighbor TLV ?. I am not sure how A will be interpreting D received from B's LSP, in case the information is carried in the ES neighbor TLV. +-----+ +-----+ | A |<------>| B | +-----+ +-----+ A A | | V V +-----+ +-----+ | D |<------>| C | +-----+ +-----+ Regards, Sumesh. Original Message----- From: Jonnala, Nagi [mailto:nagij@netplane.com] Sent: Wednesday, May 07, 2003 12:31 PM To: Jonnala, Nagi; 'Sumesh K P'; isis-wg@ietf.org Subject: RE: [Isis-wg] clns static routes exporting to is-is >>Case - 2 >>------------- >>A is an IS and does not run IS-IS. >>B and C are ISs and runs IS-IS in dual-mode. >>Static clnp IS route to A is configured at B. >>Should this IS information be carried in B's IS neighbor TLV ?. >You claim that A is an IS. In the topology, though it is not >connected to any other ISs. If that is the case, I think it doesn't >really matter if you advertise it in ES neighbor TLV (or) IS neighbor TLV >because anyway it is a leaf node. >On contrary, if A is connected to other ISs (hope fully running IS-IS >protocol among them and obviously it has got some LSPs). >In this case, you CAN choose to advertise it in IS neighbor TLV >since it has got some network topology to be considered in SPF. I'm wrong. You should always advertise it in ES neighbor TLV but never in IS neighbors TLV. The reason is that it might create lot of issues if you advertise it in IS neighbor TLV and the link is down for some reason and you never know it is down since it is a static route. Thanks to Vishwas for the offline discussion. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 8 04:11:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15531 for ; Thu, 8 May 2003 04:11:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488IV819757; Thu, 8 May 2003 04:18:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488Hs819716 for ; Thu, 8 May 2003 04:17:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15447 for ; Thu, 8 May 2003 04:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DgTd-0000xZ-00 for isis-wg@ietf.org; Thu, 08 May 2003 04:10:05 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19DgTc-0000xG-00 for isis-wg@ietf.org; Thu, 08 May 2003 04:10:05 -0400 Received: from l04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEK0054T6LMEO@mta0.huawei.com> for isis-wg@ietf.org; Thu, 08 May 2003 16:08:11 +0800 (CST) From: lidefeng To: isis-wg@ietf.org Message-id: <00eb01c31539$30e2e080$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Isis-wg] Question About the wide-metric TLV. Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 May 2003 16:09:46 +0800 Content-Transfer-Encoding: 7BIT Dear all: I have a doubt about how to use the new wide-metric TLV to express the internal/external reachability route. You know, previously, TLV 128 indicates the route of internal reachability and TLV 130 indicates the route of external reachability. TLV 135 is in replace of the two TLVs in the request of wide-metric. But I can't find any bit of the new TLV to be used to distinguish the route of internal/external reachability. Anyone can help to clarify my confusion? Thanks a lot ! regards shiny _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 8 11:42:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27155 for ; Thu, 8 May 2003 11:42:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48FnK823092; Thu, 8 May 2003 11:49:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Fhf822712 for ; Thu, 8 May 2003 11:43:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26758 for ; Thu, 8 May 2003 11:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DnQs-0003Zu-00 for isis-wg@ietf.org; Thu, 08 May 2003 11:35:42 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19DnQr-0003Zp-00 for isis-wg@ietf.org; Thu, 08 May 2003 11:35:42 -0400 Received: from there (dhcp-bru-peg2-vl28-144-254-0-118.cisco.com [144.254.0.118]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h48Fa2R12999; Thu, 8 May 2003 17:36:02 +0200 (CEST) Message-Id: <200305081536.h48Fa2R12999@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Alex Zinin , isis-wg@ietf.org Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 X-Mailer: KMail [version 1.3.1] Cc: Acee Lindem References: <165181004120.20030505173410@psg.com> In-Reply-To: <165181004120.20030505173410@psg.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48Fhf822713 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 May 2003 17:35:49 +0200 Content-Transfer-Encoding: 8bit On Tuesday 06 May 2003 02:34, Alex Zinin wrote: > Folks- > > I reviewed the draft and had an opportunity to discuss my comments > with the authors and the WG chairs. Below is the summary. I also > include comments from the rtg-dir--thanks, Acee. > > Meta: Why do we need two tag TLVs? > > This is still an open question for me. > > Clearly, one 32-bit tag is enough to control prefix distribution > throughout the domain. Two tags complicate both the specification > and operation of the network, as we have to deal with some > "interesting" questions, like whether the implementations should > be able act upon (filter prefixes based on) just one TLV or both, > and whether the two TLVs operate on the same (64-bit) value space > (with one covering only 1/2) or on separate ones, and how they > should work together. > > So, I studied the ML archives looking for clue and I found that the > main motivation for the 64-bit tag appears to be transporting of > Extended Communities for a certain case of 2547 deployment. If > that's the case, than it seems that a better approach would be to > specify the 64-bit TLV as a "BGP " or "VPN " > and be honest about it's functionality than to have two tags. > > I'd love to hear more on this topic. me too. I tend to agree with you about using a separate (sub)TLV. > We had an agreement on the rest of the issues below. > > 1. Discourage incompatible intra-area SPF modifications > > There is a case where one could potentially use a tag value to > decide to not install a prefix in the routing table during > intra-area RT calculation and get into loops or blackholes. Some > words should be put in the text saying that implementations should > not use tags to change their intra-area routing calculation in a way > that would make it inconsistent with ISO 10589. I naively thought it was implicit that routing calculation should be consistent.... > 2. Require compliant implementations to support prefix filtering at > area borders > > The draft definitely reads like filtering at the area boundaries > is one of the major applications of this TLV. However, because the > document requests the compliant implementations to only be able to > insert the tag, but not filter using it at the L1/L2 IS'es, an > operator cannot expect all compliant implementations to be useful > for this function, i.e., they will need to ask if functions > outside the scope of this document are supported by specific > vendors, go into details of how they do that to make sure > different implementations can work together in a consistent way. > Putting in 'MUST support filtering at the area boundaries' would > solve this. ok. > 3. Processing of multiple instances of the TLV. > > I could see some implementations deciding to merge the tag sets, > and some using just the first (or the last) instance, which would > result in interop issues. We need consistency in behavior. > > The proposal was to put text saying that only the first copy of > the TLV must be considered. ok > 4. Tag ordering clarifications > > Text in section 6 needs to be clarified to make it explicit that > [re]ordering of tags makes sense only when L1/L2 route leaking is > performed. L1/L2 and L2/L1 s. > 5. IANA considerations > > Change the text to say "This document defines..." > > 6. Comments from rtg-dir: > > > 1. The last sentence of the abstract doesn't make sense. "Additionally, > > the information can be placed in LSPs that have TLVs as yet > > undefined, if this information is used to convey the same > > meaning in these future TLVs as it used in the currently defined > > TLVs". Suggested - "The administrative tag sub-TLVs may be used with > > with future TLVs as long as their semantics are preserved." > > > > 2. Section 5.2 - The value of the type is wrong - it should be 2 rather > > than 1. > > > > 3. Section 6 says the ordering of tags is not significant. However, the > > previous sections (5.1 and 5.2) say that an implementation may only > > consider the first tag. > > > > 4. Section 7 - List the requirements for receiving the new Sub-TLVs in > > this compliance section as well (even if they were stated previously). > > > > 5. Section 8 - The example talks about R2 associating tag 110 with property > > A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with property > > A is adjacent to R1 (which applies to me that R1 originate the prefix). > > Please fix either the example or the figure. > > Nits below: > > > 1. Status of this Memo > > Shouldn't be numbered > > > 2. Abstract > > The rfc-ed will not like the references in the abstract, > please remove. > > > 5.1. 32-bit Administrative Tag Sub-TLV 1 > > > > The Administrative Tag shall be encoded as one or more 4 octet > > unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The > > Administrative Tag Sub-TLV has following structure: > > > > 1 octet of type (value: 1) > > 1 octet of length (value: multiple of 4) > > one or more instances of 4 octets of administrative tag > > Would be great if we had the same format as in RFC1195, or 3373 > for consistency. Using IETF format is an option too. > > Ditto for 5.2 > > > > 12. References > > Please split them to normative and informative like below: > > 12. Normative References > > [1] "Intermediate System to Intermediate System Intra-Domain Routeing > Exchange Protocol for use in Conjunction with the Protocol for > Providing the Connectionless-mode Network Service (ISO 8473)", > ISO 10589. > > [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and > dual environments", RFC 1195, December 1990. > > [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", > Internet Draft, "Work in Progress", September 2000. > > [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution > with Two-Level IS-IS" RFC 2966, October 2000 > > 13. Informative References > > [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, > J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, > September 1999. > > [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > 2002. > > Nits from Acee: > > > 1. The abstract contains references. The documents should be specified > > by name since the abstract can be excerpted. > > > > 2. Line 323 over 72 chars. > > > > Line 323 length is 74 > > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > > > > 3. Pages 2, 3, 4, and 5 have over 58 lines. > > Thanks! > -- > Alex Zinin > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 8 12:15:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28557 for ; Thu, 8 May 2003 12:15:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48GMB826398; Thu, 8 May 2003 12:22:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48GL3826290 for ; Thu, 8 May 2003 12:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28304 for ; Thu, 8 May 2003 12:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Do12-0003ti-00 for isis-wg@ietf.org; Thu, 08 May 2003 12:13:04 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19Do11-0003tS-00 for isis-wg@ietf.org; Thu, 08 May 2003 12:13:03 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h48GDGR26348; Thu, 8 May 2003 18:13:16 +0200 From: Hannes Gredler To: lidefeng Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Question About the wide-metric TLV. Message-ID: <20030508161316.GA26325@juniper.net> References: <00eb01c31539$30e2e080$07436e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00eb01c31539$30e2e080$07436e0a@HUAWEI.COM> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 May 2003 18:13:16 +0200 On Thu, May 08, 2003 at 04:09:46PM +0800, lidefeng wrote: | Dear all: | I have a doubt about how to use the new wide-metric TLV to express the | internal/external reachability route. | You know, previously, TLV 128 indicates the route of internal reachability | and TLV 130 indicates the route of | external reachability. TLV 135 is in replace of the two TLVs in the request | of wide-metric. But I can't find any bit of the new TLV to be used to | distinguish the route of internal/external reachability. | Anyone can help to clarify my confusion? Thanks a lot ! the authors of the draft did not carry the internal/external semantics of the old-style TLVs forward b/c of limited use of such a bit; i.e. there is no I/E bit for TLV135; part of the motivation was also that there are simply no bits in the control block left and they did not to spend another byte; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 8 21:00:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18297 for ; Thu, 8 May 2003 21:00:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4918N804901; Thu, 8 May 2003 21:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4917r804880 for ; Thu, 8 May 2003 21:07:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18226 for ; Thu, 8 May 2003 20:57:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DwEh-000089-00 for isis-wg@ietf.org; Thu, 08 May 2003 20:59:43 -0400 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 19DwEh-000081-00 for isis-wg@ietf.org; Thu, 08 May 2003 20:59:43 -0400 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id ; Thu, 8 May 2003 21:00:08 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB3503E289A2@entmail.gnilink.com> From: "Martin, Christian" To: "'stefano previdi'" , Alex Zinin , isis-wg@ietf.org Cc: Acee Lindem Subject: RE: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C315C6.52E3E200" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 May 2003 21:00:03 -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_01C315C6.52E3E200 Content-Type: text/plain Stefano, Alex, Acee, I will make the adjustments requested. How shall I resubmit the draft? Since it is already in the queue, is it moe appropriate to send directly to the rfc-ed? Thanks! -chris >-----Original Message----- >From: stefano previdi [mailto:sprevidi@cisco.com] >Sent: Thursday, May 08, 2003 11:36 AM >To: Alex Zinin; isis-wg@ietf.org >Cc: Acee Lindem >Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 > > >On Tuesday 06 May 2003 02:34, Alex Zinin wrote: >> Folks- >> >> I reviewed the draft and had an opportunity to discuss my comments >> with the authors and the WG chairs. Below is the summary. I also >> include comments from the rtg-dir--thanks, Acee. >> >> Meta: Why do we need two tag TLVs? >> SNIP >> Thanks! >> -- >> Alex Zinin >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg >> >> >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > ------_=_NextPart_001_01C315C6.52E3E200 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01

Stefano, Alex, Acee,

I will make the adjustments requested.  How = shall I resubmit the draft?  Since it is already in the queue, is = it moe appropriate to send directly to the rfc-ed?

Thanks!
-chris

>-----Original Message-----
>From: stefano previdi [mailto:sprevidi@cisco.com] =
>Sent: Thursday, May 08, 2003 11:36 AM
>To: Alex Zinin; isis-wg@ietf.org
>Cc: Acee Lindem
>Subject: Re: [Isis-wg] AD-review of = draft-ietf-isis-admin-tags-01
>
>
>On Tuesday 06 May 2003 02:34, Alex Zinin = wrote:
>> Folks-
>>
>>  I reviewed the draft and had an = opportunity to discuss my comments 
>> with the authors and the WG chairs. Below = is the summary. I also 
>> include comments from the rtg-dir--thanks, = Acee.
>>
>>  Meta: Why do we need two tag = TLVs?
>>

SNIP

>> Thanks!
>> --
>> Alex Zinin
>>
>> = _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg
>>
>>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01C315C6.52E3E200-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 8 21:44:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19207 for ; Thu, 8 May 2003 21:44:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h491pB807542; Thu, 8 May 2003 21:51:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h491nr807432 for ; Thu, 8 May 2003 21:49:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19068 for ; Thu, 8 May 2003 21:39:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DwtK-0000N0-00 for isis-wg@ietf.org; Thu, 08 May 2003 21:41:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19DwtK-0000Mx-00 for isis-wg@ietf.org; Thu, 08 May 2003 21:41:42 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19DwuA-000NMi-00; Fri, 09 May 2003 01:42:34 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <48169983102.20030508183647@psg.com> To: "Martin, Christian" CC: "'stefano previdi'" , isis-wg@ietf.org, Acee Lindem Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 In-Reply-To: <94B9091E1149D411A45C00508BACEB3503E289A2@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB3503E289A2@entmail.gnilink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 May 2003 18:36:47 -0700 Content-Transfer-Encoding: 7bit Christian, > Stefano, Alex, Acee, > I will make the adjustments requested. How shall I resubmit the draft? > Since it is already in the queue, is it moe appropriate to send directly to > the rfc-ed? I suggest we wait until Naming is back--I think he was the one who suggested the 64-bit tag, I pinged him today and he's out of the office till 12th. When the agreement is reached, you should resubmit the draft as usual, and ping the WG chairs and me. Tony's will take a look and see if another WG LC is due, or not. Once they are comfortable, I'll take it to the IESG and will request the IETF Last Call. Thanks. Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 09:12:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14723 for ; Fri, 9 May 2003 09:12:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49DJe805274; Fri, 9 May 2003 09:19:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49DI2805177 for ; Fri, 9 May 2003 09:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14600 for ; Fri, 9 May 2003 09:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E7d2-00049Q-00 for isis-wg@ietf.org; Fri, 09 May 2003 09:09:36 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19E7d1-00049J-00 for isis-wg@ietf.org; Fri, 09 May 2003 09:09:35 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49DA0K04022 for ; Fri, 9 May 2003 09:10:00 -0400 (EDT) Received: from zcard04e.ca.nortel.com ([47.129.242.64]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFN8VM; Fri, 9 May 2003 09:10:00 -0400 Received: from americasm01.nt.com (wcars0rx.ca.nortel.com [47.128.148.154]) by zcard04e.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 23JD7CAM; Fri, 9 May 2003 09:10:00 -0400 Message-ID: <3EBBA8A7.D5453A72@americasm01.nt.com> From: "Ruth Civil" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Lack of I/E bit in TLV 135 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 May 2003 09:09:59 -0400 Content-Transfer-Encoding: 7bit There was a quick exchange on this mailing list a couple of days ago where someone asked about the lack of an I/E bit in the Extended IP Reachability TLV (type 135). The response was that it wasn't included because it was more or less useless. What happens if an ISIS router using wide metrics needs to distinguish between internal and external routes in order to apply different route preferences to internal vs external routes ? I believe there are some routers (most notably Juniper) which offer the ability to configure both a preference (for internal routes) and an external-preference (for external routes). What method could such routers be using to distinguish between internal and external routes in order to apply those different preferences (when wide metrics are being used) ? - Ruth -- Ruth Civil Routing development ESN 6 395 1142 rxc@nortelnetworks.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 14:11:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25527 for ; Fri, 9 May 2003 14:11:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49IIE831452; Fri, 9 May 2003 14:18:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49IGK831251 for ; Fri, 9 May 2003 14:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25140 for ; Fri, 9 May 2003 14:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECHc-0006Gk-00 for isis-wg@ietf.org; Fri, 09 May 2003 14:07:48 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19ECHb-0006GL-00 for isis-wg@ietf.org; Fri, 09 May 2003 14:07:47 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 2AB2D23C59; Fri, 9 May 2003 10:56:48 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h49I8DYB012658; Fri, 9 May 2003 11:08:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135 Message-ID: Thread-Topic: [Isis-wg] Lack of I/E bit in TLV 135 Thread-Index: AcMWLSSUtcESGt8RRTGckVsVDafcIwAKJ4AQ From: "Tony Li" To: "Ruth Civil" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49IGK831252 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 May 2003 11:08:13 -0700 Content-Transfer-Encoding: 8bit One might use an administrative tag... this would allow you to describe more semantics than simply I/E. BTW, just because something is in an implementation doesn't necessarily mean that the programmer thought it was a good idea. Tony | -----Original Message----- | From: Ruth Civil [mailto:rxc@nortelnetworks.com] | Sent: Friday, May 09, 2003 6:10 AM | To: isis-wg@ietf.org | Subject: [Isis-wg] Lack of I/E bit in TLV 135 | | | There was a quick exchange on this mailing list a couple | of days ago | where someone asked about the lack of an I/E bit in the Extended IP | Reachability TLV (type 135). | | The response was that it wasn't included because it was | more or less | useless. | | What happens if an ISIS router using wide metrics needs to | distinguish | between internal and external routes in order to apply | different route | preferences to internal vs external routes ? | | I believe there are some routers (most notably Juniper) | which offer the | ability to configure both a preference (for internal routes) and an | external-preference (for external routes). What method could such | routers be using to distinguish between internal and | external routes in | order to apply those different preferences (when wide | metrics are being | used) ? | | | - Ruth | | -- | Ruth Civil | Routing development | ESN 6 395 1142 | rxc@nortelnetworks.com | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 14:35:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26530 for ; Fri, 9 May 2003 14:35:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49If9801460; Fri, 9 May 2003 14:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Ie5801352 for ; Fri, 9 May 2003 14:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26217 for ; Fri, 9 May 2003 14:29:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECeb-0006Uw-00 for isis-wg@ietf.org; Fri, 09 May 2003 14:31:33 -0400 Received: from nn6.excitenetwork.com ([207.159.120.60] helo=xmxpita.excite.com) by ietf-mx with esmtp (Exim 4.12) id 19ECea-0006Uo-00 for isis-wg@ietf.org; Fri, 09 May 2003 14:31:32 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 78E783DC3; Fri, 9 May 2003 14:31:57 -0400 (EDT) To: isis-wg@ietf.org Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135 Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Fri, 09 May 2003 14:31:57 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: rxc@nortelnetworks.com Message-Id: <20030509183157.78E783DC3@xmxpita.excite.com> Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 May 2003 14:31:57 -0400 (EDT) Content-Transfer-Encoding: 7bit Ruth, Presumably, the router injecting the external routes into ISIS would either add to the metric to "poison" them, or one could possibly use the newer admin tags to "color" them. Of course, someone else might have a better suggestion... -don --- On Fri 05/09, Ruth Civil < rxc@nortelnetworks.com > wrote: From: Ruth Civil [mailto: rxc@nortelnetworks.com] To: isis-wg@ietf.org Date: Fri, 09 May 2003 09:09:59 -0400 Subject: [Isis-wg] Lack of I/E bit in TLV 135 There was a quick exchange on this mailing list a couple of days ago
where someone asked about the lack of an I/E bit in the Extended IP
Reachability TLV (type 135).

The response was that it wasn't included because it was more or less
useless.

What happens if an ISIS router using wide metrics needs to distinguish
between internal and external routes in order to apply different route
preferences to internal vs external routes ?

I believe there are some routers (most notably Juniper) which offer the
ability to configure both a preference (for internal routes) and an
external-preference (for external routes). What method could such
routers be using to distinguish between internal and external routes in
order to apply those different preferences (when wide metrics are being
used) ?


- Ruth

--
Ruth Civil
Routing development
ESN 6 395 1142
rxc@nortelnetworks.com
________________________________ _______________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 15:39:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29599 for ; Fri, 9 May 2003 15:39:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49JhC806461; Fri, 9 May 2003 15:43:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49JgF806401 for ; Fri, 9 May 2003 15:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29298 for ; Fri, 9 May 2003 15:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EDcj-0006tn-00 for isis-wg@ietf.org; Fri, 09 May 2003 15:33:41 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19EDci-0006tR-00 for isis-wg@ietf.org; Fri, 09 May 2003 15:33:40 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49JY5p06285 for ; Fri, 9 May 2003 15:34:06 -0400 (EDT) Received: from zcard04e.ca.nortel.com ([47.129.242.64]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL1KPYM; Fri, 9 May 2003 15:34:05 -0400 Received: from americasm01.nt.com (wcars0rx.ca.nortel.com [47.128.148.154]) by zcard04e.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 23JD7CSY; Fri, 9 May 2003 15:34:06 -0400 Message-ID: <3EBC02AD.860485C6@americasm01.nt.com> From: "Ruth Civil" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@ietf.org Subject: Re: [Isis-wg] Lack of I/E bit in TLV 135 References: <20030509183157.78E783DC3@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 May 2003 15:34:05 -0400 Content-Transfer-Encoding: 7bit Don Goodspeed wrote: > > > Presumably, the router injecting the external routes into ISIS > would either add to the metric to "poison" them, or one could > possibly use the newer admin tags to "color" them. I understand the admin tags suggestion, but I'm not sure the "poisoning" suggestion actually resolves the situation I had in mind. I was referring to the situation where ISIS has only one route (and that route happens to be an external route) to a destination X, but it has no means by which to know the route is external (due to the lack of an I/E bit in TLV 135). The network operator may wish to prefer an ISIS Internal route to an OSPF one, but prefer the OSPF one to an External ISIS route; but if you cannot distinguish between the internal and external ISIS routes then you can't do this. If I'm correctly interpreting what you mean by "poisoning" here then this would certainly cause ISIS itself to chose an internal route to destination X if it had one. However, assuming ISIS didn't have an internal route to X, "poisoning" still wouldn't provide the ability to identify the chosen route to X as an External ISIS route when it was submitted to the routing table. Alternatively, you may be proposing that we make the assumption that ISIS routes with metrics larger than a certain predetermined value are always external ones, and report them as such when submitting them to the routing table, but this sounds a bit iffy to me. I guess what I'm hearing from the replies I've been getting here is that the authors of RFC 2966 believed that the ability to enforce an order of preference such as: Internal ISIS > Other Protocol > External ISIS was either unnecessary or unimportant. This designer may not necessarily think it's particularly important either, but may still be forced to investigate the viability of implementing such a scheme ... - Ruth > > Of course, someone else might have a better suggestion... > > -don > > --- On Fri 05/09, Ruth Civil < rxc@nortelnetworks.com > wrote: > From: Ruth Civil [mailto: rxc@nortelnetworks.com] > To: isis-wg@ietf.org > Date: Fri, 09 May 2003 09:09:59 -0400 > Subject: [Isis-wg] Lack of I/E bit in TLV 135 > > There was a quick exchange on this mailing list a couple of days ago
where someone asked about the lack of an I/E bit in the Extended IP
Reachability TLV (type 135).

The response was that it wasn't included because it was more or less
useless.

What happens if an ISIS router using wide metrics needs to distinguish
between internal and external routes in order to apply different route
preferences to internal vs external routes ?

I believe there are some routers (most notably Juniper) which offer the
ability to configure both a preference (for internal routes) and an
external-preference (for external routes). What method could such
routers be using to distinguish between internal and external routes in
order to apply those different preferences (when wide metrics are being
used) ? _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 19:09:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06844 for ; Fri, 9 May 2003 19:09:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49NHO823969; Fri, 9 May 2003 19:17:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49NEv823911 for ; Fri, 9 May 2003 19:14:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06720 for ; Fri, 9 May 2003 19:04:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EGwV-0000U3-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:06:19 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19EGwT-0000Tn-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:06:18 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h49N6Zo30571; Sat, 10 May 2003 01:06:35 +0200 From: Hannes Gredler To: Ruth Civil Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Lack of I/E bit in TLV 135 Message-ID: <20030509230635.GA30550@juniper.net> References: <20030509183157.78E783DC3@xmxpita.excite.com> <3EBC02AD.860485C6@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBC02AD.860485C6@americasm01.nt.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 01:06:35 +0200 On Fri, May 09, 2003 at 03:34:05PM -0400, Ruth Civil wrote: | Don Goodspeed wrote: | > | > | > Presumably, the router injecting the external routes into ISIS | > would either add to the metric to "poison" them, or one could | > possibly use the newer admin tags to "color" them. | | I understand the admin tags suggestion, but I'm not sure the "poisoning" | suggestion actually resolves the situation I had in mind. | | I was referring to the situation where ISIS has only one route (and that | route happens to be an external route) to a destination X, but it has no | means by which to know the route is external (due to the lack of an I/E | bit in TLV 135). The network operator may wish to prefer an ISIS | Internal route to an OSPF one, but prefer the OSPF one to an External | ISIS route; but if you cannot distinguish between the internal and | external ISIS routes then you can't do this. correct ... but i guess they main question is how IS-IS is really used today ? the common way is to use it as some kind of topological discovery tool and mostly it does just carry loopback and link adresses; typically no customer reachability information is contained as there are protocols that can deal much better with bulk routes; if i just want to use it as a topo discovery tool and for bringing up the iBGP mesh then the whole I/E information is not used at all as all loopbacks are internal anyway; | If I'm correctly interpreting what you mean by "poisoning" here then | this would certainly cause ISIS itself to chose an internal route to | destination X if it had one. However, assuming ISIS didn't have an | internal route to X, "poisoning" still wouldn't provide the ability to | identify the chosen route to X as an External ISIS route when it was | submitted to the routing table. Alternatively, you may be proposing that | we make the assumption that ISIS routes with metrics larger than a | certain predetermined value are always external ones, and report them as | such when submitting them to the routing table, but this sounds a bit | iffy to me. /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 19:19:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07023 for ; Fri, 9 May 2003 19:19:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49NR5824192; Fri, 9 May 2003 19:27:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49NOa824144 for ; Fri, 9 May 2003 19:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06907 for ; Fri, 9 May 2003 19:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EH5p-0000Wh-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:15:57 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19EH5o-0000Wd-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:15:56 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h49NGJt30590; Sat, 10 May 2003 01:16:19 +0200 From: Hannes Gredler To: Alex Zinin Cc: isis-wg@ietf.org, Acee Lindem Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 Message-ID: <20030509231618.GB30550@juniper.net> References: <165181004120.20030505173410@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165181004120.20030505173410@psg.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 01:16:18 +0200 On Mon, May 05, 2003 at 05:34:10PM -0700, Alex Zinin wrote: | Folks- | | I reviewed the draft and had an opportunity to discuss my comments | with the authors and the WG chairs. Below is the summary. I also | include comments from the rtg-dir--thanks, Acee. | | Meta: Why do we need two tag TLVs? | | This is still an open question for me. | | Clearly, one 32-bit tag is enough to control prefix distribution | throughout the domain. Two tags complicate both the specification | and operation of the network, as we have to deal with some | "interesting" questions, like whether the implementations should | be able act upon (filter prefixes based on) just one TLV or both, | and whether the two TLVs operate on the same (64-bit) value space | (with one covering only 1/2) or on separate ones, and how they | should work together. the basic idea was that today most SPs do run VPN environments and today there are well established tagging schemes; typically those tag-spaces are based on extd. BGP communties which are 64-bits in size; so the question from an administration point of view is wether it makes sense to create another 32 bit tag-space or to let implementations allow to map those tags 1:1 to IS-IS admin tags; i do agree that there should be a section in the draft that should cover 32-bit / 64-bit tag interaction; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 9 19:42:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07489 for ; Fri, 9 May 2003 19:42:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Np8826124; Fri, 9 May 2003 19:51:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49NmB826018 for ; Fri, 9 May 2003 19:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07414 for ; Fri, 9 May 2003 19:37:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EHSe-0000fY-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:39:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19EHSd-0000fV-00 for isis-wg@ietf.org; Fri, 09 May 2003 19:39:31 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19EHTX-000PrZ-00; Fri, 09 May 2003 23:40:27 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <32249272014.20030509163816@psg.com> To: Hannes Gredler CC: isis-wg@ietf.org, Acee Lindem Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 In-Reply-To: <20030509231618.GB30550@juniper.net> References: <165181004120.20030505173410@psg.com> <20030509231618.GB30550@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 May 2003 16:38:16 -0700 Content-Transfer-Encoding: 7bit Hannes, > the basic idea was that today most SPs do run VPN environments and > today there are well established tagging schemes; > typically those tag-spaces are based on extd. BGP communties > which are 64-bits in size; if this is the case, then how about this: it seems that a better approach would be to specify the 64-bit TLV as a "BGP " or "VPN " and be honest about it's functionality than to have two tags. Thanks. Alex > so the question from an administration point of view is wether it > makes sense to create another 32 bit tag-space or to let implementations > allow to map those tags 1:1 to IS-IS admin tags; > i do agree that there should be a section in the draft that should > cover 32-bit / 64-bit tag interaction; > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 12 12:05:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22363 for ; Mon, 12 May 2003 12:05:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CFPYB07698; Mon, 12 May 2003 11:25:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CFO0B07650 for ; Mon, 12 May 2003 11:24:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21920 for ; Mon, 12 May 2003 11:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FFiS-0002ME-00 for isis-wg@ietf.org; Mon, 12 May 2003 11:59:52 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19FFiO-0002M2-00 for isis-wg@ietf.org; Mon, 12 May 2003 11:59:49 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h4CFxxf17430; Mon, 12 May 2003 17:59:59 +0200 From: Hannes Gredler To: Alex Zinin Cc: isis-wg@ietf.org, Acee Lindem Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 Message-ID: <20030512155959.GA17352@juniper.net> References: <165181004120.20030505173410@psg.com> <20030509231618.GB30550@juniper.net> <32249272014.20030509163816@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32249272014.20030509163816@psg.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 17:59:59 +0200 On Fri, May 09, 2003 at 04:38:16PM -0700, Alex Zinin wrote: | Hannes, | | > the basic idea was that today most SPs do run VPN environments and | > today there are well established tagging schemes; | > typically those tag-spaces are based on extd. BGP communties | > which are 64-bits in size; | | if this is the case, then how about this: | | it seems that a better approach would be to | specify the 64-bit TLV as a "BGP " or "VPN " | and be honest about it's functionality than to have two tags. IMO tag-32 is not explicit about its purpose, either; i.e. could be a tag that controls L2L1 leaking but could be also a tag which controls origin related information for better troubleshooting information; the function of the tag-32 has deliberlatly been left open: why is there a need to be that firm about the usage of a 64-bit tag ? i don't see the benefit of having several different 64-bit tags - some clarification in the draft describing some sample applications for a general 64-bit tag ought to be enough; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 12 15:59:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01536 for ; Mon, 12 May 2003 15:59:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CJMKB26633; Mon, 12 May 2003 15:22:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CJHcB26237 for ; Mon, 12 May 2003 15:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01146 for ; Mon, 12 May 2003 15:51:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FJMT-00040o-00 for isis-wg@ietf.org; Mon, 12 May 2003 15:53:25 -0400 Received: from net4u.net4u.ch ([194.191.0.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19FJMS-00040l-00 for isis-wg@ietf.org; Mon, 12 May 2003 15:53:24 -0400 Received: from net4u.ch (zux006-012-144.adsl.green.ch [81.6.12.144]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h4CJsMR18720; Mon, 12 May 2003 21:54:22 +0200 Message-ID: <3EBFFBE9.3010809@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Gredler CC: Alex Zinin , isis-wg@ietf.org, Acee Lindem Subject: Re: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01 References: <165181004120.20030505173410@psg.com> <20030509231618.GB30550@juniper.net> <32249272014.20030509163816@psg.com> <20030512155959.GA17352@juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 21:54:17 +0200 Content-Transfer-Encoding: 7bit Hannes Gredler wrote: >On Fri, May 09, 2003 at 04:38:16PM -0700, Alex Zinin wrote: >| Hannes, >| >| > the basic idea was that today most SPs do run VPN environments and >| > today there are well established tagging schemes; >| > typically those tag-spaces are based on extd. BGP communties >| > which are 64-bits in size; >| >| if this is the case, then how about this: >| >| it seems that a better approach would be to >| specify the 64-bit TLV as a "BGP " or "VPN " >| and be honest about it's functionality than to have two tags. > >IMO tag-32 is not explicit about its purpose, either; >i.e. could be a tag that controls L2L1 leaking but could be also >a tag which controls origin related information for better troubleshooting >information; the function of the tag-32 has deliberlatly been left open: >why is there a need to be that firm about the usage of a 64-bit tag ? > >i don't see the benefit of having several different 64-bit tags - some >clarification in the draft describing some sample applications for >a general 64-bit tag ought to be enough; > agreed, the draft gains nothing by specifying that the 64-bit MUST be used for VPN purposes. It may very well later be used for other things. As an _example_ though, the VPN application would be fine. -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 12 16:10:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02045 for ; Mon, 12 May 2003 16:10:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CJXZB27481; Mon, 12 May 2003 15:33:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CJWeB27401 for ; Mon, 12 May 2003 15:32:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01865 for ; Mon, 12 May 2003 16:06:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FJb0-0004Ci-00 for isis-wg@ietf.org; Mon, 12 May 2003 16:08:26 -0400 Received: from net4u.net4u.ch ([194.191.0.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19FJb0-0004Cc-00 for isis-wg@ietf.org; Mon, 12 May 2003 16:08:26 -0400 Received: from net4u.ch (zux006-012-144.adsl.green.ch [81.6.12.144]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h4CK9JR22197; Mon, 12 May 2003 22:09:19 +0200 Message-ID: <3EBFFF62.8000008@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Ruth Civil , isis-wg@ietf.org Subject: Re: [Isis-wg] Lack of I/E bit in TLV 135 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 22:09:06 +0200 Content-Transfer-Encoding: 7bit Tony Li wrote: >One might use an administrative tag... this would allow you >to describe more semantics than simply I/E. > > didn't christian write a while ago a draft on sub-TLV in 135 that carried the external/internal? - tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon May 12 23:19:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12564 for ; Mon, 12 May 2003 23:19:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2hLB25194; Mon, 12 May 2003 22:43:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2gBB25165 for ; Mon, 12 May 2003 22:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12502 for ; Mon, 12 May 2003 23:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FQIX-0006dW-00 for isis-wg@ietf.org; Mon, 12 May 2003 23:17:49 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19FQIV-0006dT-00 for isis-wg@ietf.org; Mon, 12 May 2003 23:17:48 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h4D3IoO0029841 for ; Mon, 12 May 2003 20:18:50 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h4D3Imbr017958 for ; Mon, 12 May 2003 22:18:49 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 23:18:35 -0400 Message-ID: From: "Manral, Vishwas" To: "'prz@net4u.ch'" , Tony Li Cc: Ruth Civil , isis-wg@ietf.org Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135 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@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 23:20:08 -0400 Hi, Wouldn't it cause routing loops if we made routing calculation decisions based on an optional feature i.e. sub-TLV? Thanks, Vishwas -----Original Message----- From: Tony Przygienda [mailto:prz@net4u.ch] Sent: Tuesday, May 13, 2003 1:39 AM To: Tony Li Cc: Ruth Civil; isis-wg@ietf.org Subject: Re: [Isis-wg] Lack of I/E bit in TLV 135 Tony Li wrote: >One might use an administrative tag... this would allow you >to describe more semantics than simply I/E. > > didn't christian write a while ago a draft on sub-TLV in 135 that carried the external/internal? - tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 13 00:54:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14865 for ; Tue, 13 May 2003 00:54:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D4IFB30625; Tue, 13 May 2003 00:18:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D4EcB30433 for ; Tue, 13 May 2003 00:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14562; Tue, 13 May 2003 00:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FRj0-00074J-00; Tue, 13 May 2003 00:49:14 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19FRiy-00073n-00; Tue, 13 May 2003 00:49:13 -0400 Received: from l04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HET00JST6O7KJ@mta0.huawei.com>; Tue, 13 May 2003 12:48:11 +0800 (CST) From: lidefeng To: internet-drafts@ietf.org Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org Message-id: <000c01c3190b$1418a540$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_wEd4UadjSmfs0tkTxbLnqw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Isis-wg] A new draft,IS-IS as PE/CE routing protocol in BGP/MPLS/VPN Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 12:49:46 +0800 This is a multi-part message in MIME format. --Boundary_(ID_wEd4UadjSmfs0tkTxbLnqw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi,all, In deploying BGP/MPLS VPN,there are sites that CE run IS-IS protocol with PE,and the corresponding customer is reluctant to change the routing protocol they used in the sites,to accomodate this situation, it is better to run isis protocol between PE and CE,however,ther isn't any draft to specify the scenario in the BGP MPLS VPN. This draft addresses this scenario,the abstract is as following: IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. --Boundary_(ID_wEd4UadjSmfs0tkTxbLnqw) Content-type: text/plain; name=draft-sheng-ppvpn-isis-bgp-mpls-00.txt Content-disposition: attachment; filename=draft-sheng-ppvpn-isis-bgp-mpls-00.txt Content-Transfer-Encoding: 7BIT Network Working Group Sheng Cheng INTERNET DRAFT Liu Yu Expiration Date: October 2003 Li Defeng Huawei Technologies. Chen Yunqing China Telecommunication April 2003 ISIS as the PE/CE Protocol in BGP/MPLS VPNs draft-sheng-isis-bgp-mpls-vpn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. Cheng Sheng Expires October 2003 [Page 1] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 Table of Contents 1 Terms ................................................. 2 2 Introduction .......................................... 2 3 Fundamental Requirments .............................. 3 3.1 Assumptions ........................................... 3 3.2 Multiple instances ................................... 3 3.3 IS-IS interaction with BGP on PE ..................... 3 3.4 Supplement............................................. 3 4 Extended Requirments .................................. 4 4.1 Sham Links ........................................... 4 4.2 Carry IS-IS imformation with BGP Extended communities . 4 4.3 Route loop prevention on PEs ......................... 5 4.4 IS-IS interaction with BGP on PE ..................... 5 4.5 Sham-link Creation ................................... 6 5 Acknowledgments ...................................... 7 6 References ........................................... 7 7 Authors' Address ..................................... 7 1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [IS-IS]. [VPN] describes a VPN service architecture, in which BGP is used to distribute IP-VPN routes between PEs in IP backbone. A CE router can then learn the routes to other CE sites in the same VPN by peering with its attached PE router through a routing protocol. The routing protocol is in charge of exchanging routes between PE and its attached CE. It has been proved till now that BGP, OSPF or RIP can help. And of course, IS-IS can do it as well. Obviously, as one of the most widely used IGPs, IS-IS is capable of distributing routes of CE to PE router. Using IS-IS on the PE-CE link is prefered especially when the VPN use IS-IS as its intra-site routing protocol, which means less administative expense and good backward compatibility. This draft is mainly focusing on proposing two different solutions, in which one is fundamental and the other is somewhat complicated, to implement IS-IS between PE and its attached CE. Cheng Sheng Expires October 2003 [Page 2] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 3. Fundamental Requirments In this part, some basic requirements have been listed out to address the issues of IS-IS working on PE-CE link. 3.1 Assumptions +-----+ +-----+ | PE1 |---------| PE2 | +-----+ +-----+ | | | | +-----+ +-----+ | CE1 | | CE2 | +-----+ +-----+ Two different sites of one VPN are not connected by direct(backdoor) link. Further, if this physical link dose exist, there is no IS-IS adjacency over the backdoor link. If this can not be avoided, the second solution described in 4 should be choosed. 3.2 Multiple instances Multiple IS-IS instances should be supported on PE, which means multiple IS-IS instances can run in one PE with each bound to one specific VRF. The relationship between IS-IS instances and VRFs is listed as follows: Multiple IS-IS instances can be associated with the same VRF (n:1). A single IS-IS instance should not be associated with multiple VRFs (1:n). Of course, a single IS-IS instance can be associated with just a single VRF. 3.3 IS-IS interaction with BGP on PE The PE router should have the capability to import IS-IS and BGP routes to/from a particular VRF with each other. When importing the BGP routes into a single IS-IS instance bound to a specific VRF on PE, the routes will always be regarded as external routes and IS-IS deliver the route with external reachability TLV(TLV 130) in IS-IS LSP. The level of the converted IS-IS LSP is decided through configuration. 3.4 supplement - There is no special toplogy limitation for PE/CE link and CE's sites. - There is no special requirement for CE router. Cheng Sheng Expires October 2003 [Page 3] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4. Extended Requirments +-----+ +-----+ L1/2| PE1 |---------| PE2 |L1/2 +-----+ +-----+ | | | | +-----+ +-----+ | CE1 |-------- | CE2 | +-----+ +-----+ Though clear and easily implemented, the solution as per 3 has some disvantages, such as: - Routes delivered from one site to another are always treated as external routes is not desirable, because it will make the "false" routes undistinguished from the "real" external routes. - When there exists backdoor link connecting two CEs which belong to two different sites of one VPN, the IS-IS intra-area routes will be prefered to the VPN-IP routes which has been regarded as IS-IS external routes. As a result, the traffic will choose the direct link between CEs instead of passing through the IP backbone, which may be not accepted. - Besides, when backdoor exists between PEs, the route loop will happen on PEs, as both PE1 and PE1 import BGP routes into IS-IS. 4.1 Assumption There exists direct (backdoor) link between two different VPN sites. Further, there is IS-IS adjacency established over the backdoor link. 4.2 Carry IS-IS imformation with BGP Extended communities Per [VPN], BGP is in charge of distributing VPN-IP routes accross the VPN backbone. It is very useful of carrying some of the important original IS-IS route information by BGP with BGP extended communities. These "important" original IS-IS route information are listed as follows: -- IS-IS Route Type Extended Communites Attribute. This attribute is required, which is enconded with a two-byte type field and the type is 0201. The third byte is encoded as follows: -- Level type: The first bit. When it is set 0, it indicates level-1 type route and the value of 1 indicates level-2 type route. Cheng Sheng Expires October 2003 [Page 4] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 -- TLV Reachability type: The second bit. When it is set 0, it indicates that the original IS-IS route is of internal reachability and the value 1 indicates external reachability . -- Metric type: The third bit. When it is set 0, it indicates the original route is of internal metric type and the value of 1 indicates external metric type. -- sham-link endpoint address: the fourth bit. When it is set 1 , it indicates the route is of sham-link endpoint address, which will be specified in 4.5. By default, this bit should be set as 0. -- IS-IS System Id Extended Communites Attribute This attribute specifies the system id of the particular VRF from which this route was exported. It is encoded with a two-byte type and the type is 0202. The system id is carried in the rest six bytes. This attribute is optional, which means it is only necessary to be carried in the sham-link endpoint address route. 4.3 Route loop prevention on PEs As per the diagram of 4, when PE1 and PE2 both import bgp routes into their attached CE sites, the route loop will happen on both PEs. To avoid the route loop, it is assumed here that both PE1 and PE2 act as L1/2 router and there exists level-1 adjacency between each PE-CE link. The mechanism of how to avoid route loop with up/down bit in IS-IS level-1 LSP is specified in [ROUTE-LEAKING]. 4.4 IS-IS interaction with BGP on PE When PE receives a VPN-IP route, it will convert the route back to IS-IS. The creation of IS-IS LSP will be based on IS-IS route original information carried by BGP extended communities(as per 4.2). For example, if the orignal IS-IS route is of level-1 type /internal reachability/internal metric type, the route will be re-converted to a level-1 intra-area route with internal metric type. Besides, the configuration for route redistribution about the IS-IS LSP information is prefered. Cheng Sheng Expires October 2003 [Page 5] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4.5 Sham-link Creation As per [OSPF-VPN], sham-link plays a very important role for an link state IGP such as IS-IS and OSPF in preventing the VPN traffic going through backdoor between CEs. Before establishing the sham-link, each end PE should be assigned an real shamlink endpoint address which can be a loopback address in VRF to which the CE belongs. Also, we should ensure that the endpoint address of one side PE is visible to the PE of the other side. The source and destination sham-link endpoint address is desigated by configuraiton. For example, as per the diagram in 4, it is necessary to establish a sham-link between PE1 and PE2. As the first step for PE1, BGP imports the loopback direct route which is desigated as source shamlink endpoint address on PE2. Next, the converted BGP route carries BGP extended communities with sham-link endpoint address bit(as per 4.2) set and IS-IS System Id Extended Communites Attribute with the value be equal to the System id of the specific IS-IS instance on the PE2. When PE1 receives the route, it checks the sham-link endpoint address bit and gets the IS-IS System Id the BGP route carry. If the endpoint address PE1 get is similar to its configured destination sham-link endpoint address, it is believed that there exists an sham-link from PE1 to PE2. Finally, PE1 adds one Neighbor reachability TLV(TLV 2) in its self-originated LSP and floods it out to CE1. Similiar process will happend on PE2. Note: when the PE found the system id of the other end of the sham-link changed, it will flush the old LSP and generate new LSP according to the new system id get from BGP route. 5. Acknowledgments The authors would like to thank yangang, heqian, xuxiaofei, weixiugang chenjie for their comments on this work. Cheng Sheng Expires October 2003 [Page 6] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 6. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)". [Also republished as RFC 1142.] [IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [BGP-EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- communities-05.txt>, Sangli, S., Tappan, D., Rekhter, Y., May 2002 [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-02.txt, Rosen, E., et. al., July, 2002 [ROUTE-LEAKING] "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, T. Li Request, October 2000 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-rosen-vpns-ospf-bgp-mpls-06.txt, Eric C. Rosen, April 2003 7. Author's Addresses: Sheng Cheng D401 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : shengc@huawei.com Liu Yu A401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : liu_yu@huawei.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Chen Yunqing Email : chenyunqing@vip.sina.com Cheng Sheng Expires October 2003 [Page 7] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 --Boundary_(ID_wEd4UadjSmfs0tkTxbLnqw)-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 13 02:35:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28856 for ; Tue, 13 May 2003 02:35:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D5wLB05721; Tue, 13 May 2003 01:58:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D5v0B05645 for ; Tue, 13 May 2003 01:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28716 for ; Tue, 13 May 2003 02:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FTKz-0000JM-00 for isis-wg@ietf.org; Tue, 13 May 2003 02:32:33 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19FTKy-0000J7-00 for isis-wg@ietf.org; Tue, 13 May 2003 02:32:32 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5A44323C2C; Mon, 12 May 2003 23:20:58 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4D6WTYB027448; Mon, 12 May 2003 23:32:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135 Message-ID: Thread-Topic: [Isis-wg] Lack of I/E bit in TLV 135 Thread-Index: AcMY/mazoUH9LSjkS2G1KWvyDzDSWgAGqdyg From: "Tony Li" To: "Manral, Vishwas" , Cc: "Ruth Civil" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4D5v1B05660 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 23:32:29 -0700 Content-Transfer-Encoding: 8bit Yes, anything that changes the semantics of an SPF would definitely be hazardous. However, when a protocol is injecting routes from a different level or from a different protocol, or exporting routes, then it is possible to filter the routes without causing (too much) danger of breaking the net. Obvious cases that still won't be addressed are creating positive feedback loops and the like. Tony | -----Original Message----- | From: Manral, Vishwas [mailto:VishwasM@netplane.com] | Sent: Monday, May 12, 2003 8:20 PM | To: 'prz@net4u.ch'; Tony Li | Cc: Ruth Civil; isis-wg@ietf.org | Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135 | | | Hi, | | Wouldn't it cause routing loops if we made routing | calculation decisions | based on an optional feature i.e. sub-TLV? | | Thanks, | Vishwas | | -----Original Message----- | From: Tony Przygienda [mailto:prz@net4u.ch] | Sent: Tuesday, May 13, 2003 1:39 AM | To: Tony Li | Cc: Ruth Civil; isis-wg@ietf.org | Subject: Re: [Isis-wg] Lack of I/E bit in TLV 135 | | | Tony Li wrote: | | >One might use an administrative tag... this would allow you | >to describe more semantics than simply I/E. | > | > | didn't christian write a while ago | a draft on sub-TLV in 135 that carried the external/internal? | - tony | | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 13 05:04:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01328 for ; Tue, 13 May 2003 05:04:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D8RKB32029; Tue, 13 May 2003 04:27:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D8QbB32002 for ; Tue, 13 May 2003 04:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01213 for ; Tue, 13 May 2003 05:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FVfj-00011K-00 for isis-wg@ietf.org; Tue, 13 May 2003 05:02:07 -0400 Received: from net4u.net4u.ch ([194.191.0.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19FVfi-00011H-00 for isis-wg@ietf.org; Tue, 13 May 2003 05:02:06 -0400 Received: from net4u.ch (zux006-012-144.adsl.green.ch [81.6.12.144]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h4D93BR04801 for ; Tue, 13 May 2003 11:03:11 +0200 Message-ID: <3EC0B4AC.4030108@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Vienna ... Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 11:02:36 +0200 Content-Transfer-Encoding: 7bit looks like I'll probably take the time to go to Vienna. I requested one 1 - 1 1/2 hours slot. Pls agenda requests to me thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 13 05:05:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01355 for ; Tue, 13 May 2003 05:05:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D8V1B32247 for ; Tue, 13 May 2003 04:31:01 -0400 Date: Tue, 13 May 2003 04:31:01 -0400 Message-ID: <20030513083101.32221.85455.Mailman@www1.ietf.org> Subject: Unsubscribed from "Isis-wg" mailing list From: isis-wg-admin@ietf.org To: isis-archive@ietf.org X-Ack: no Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: You have been unsubscribed from the isis-wg mailing list From isis-wg-admin@ietf.org Sun May 25 11:10:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03530 for ; Sun, 25 May 2003 11:10:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PF7jB09904; Sun, 25 May 2003 11:07:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PF4wB08958 for ; Sun, 25 May 2003 11:04:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03394; Sun, 25 May 2003 11:04:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Jx1u-0006XR-00; Sun, 25 May 2003 11:03:22 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19Jx1r-0006XL-00; Sun, 25 May 2003 11:03:20 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h4PF3VV15108; Sun, 25 May 2003 17:03:31 +0200 From: Hannes Gredler To: "Martin, Christian" Cc: "'Acee Lindem'" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030525150331.GA15087@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> User-Agent: Mutt/1.3.28i X-MIME-Autoconverted: from 8bit to quoted-printable by ghostrider.gredler.at id h4PF3VV15108 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4PF4wB08959 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 May 2003 17:03:31 +0200 Content-Transfer-Encoding: 8bit pls, keep in mind that there is already code in production that allows more than one tag; common use i have seen so far is tag #1 controls L2L1 leakage tag #2 for informational purposes and points to the area of origin; /hannes On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | RE: Comments on | | Acee, | | As the original goal was to create a capability similar to OSPF's route tag, | it may be wise to drop this capability.  On the otherhand, having multiple | tags per route can provide more information about the route than a single | tag.  In this regard, the 32 bit tag operates more like a community, and the | 64 bit tag operates like an extended community.  From an implementation | perspective, the same routines for matching and setting these fields should | be similar to the community fields in BGP. | | I would like to solicit the WG for comments on which capability is most | attractive.  The goal is not to introduce too much bloat (is it too late for | that?!) while still providing some flexibility. | | As soon as I receive any final comments, I will release the updated draft. | | Thanks for pointing out this critical piece! | | Regards, | chris | | >-----Original Message----- | >From: Acee Lindem [mailto:acee@redback.com] | >Sent: Friday, May 23, 2003 1:50 PM | >To: Acee Lindem | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >Directorate | >Subject: Re: Comments on | > | > | >Christian, Stefano, Brad, | > | >The follow-up discussion on the necessity for both 32 bit and | >64 bit tags raises the question as to whether or not it is | >wise to allow an arbitrary number of tags to be advertised. | > | >       This draft proposes 2 new "Administrative Tag" sub-TLVs | >to be added | >       to TLV 135 and 235.  These TLVs specify one or more | >ordered, 32 or 64 | >                                                  ~~~~~~~~~~~~~~~ | >       bit unsigned integers that may be associated with an IP prefix. | > | >However, the receiver need only use the first. | > | >       An implementation may consider only one of the encoded | >tags, in which | >       case the first encoded tag must be considered.  A tag | >value of zero | >       is reserved and should be treated as "no tag". | > | >IMHO, allowing an arbitrary number of tags affords more | >potential for interoperability and deviant applications than | >the 64 bit tag. | > | > | > | > | > | >Acee Lindem wrote: | >> As a member of the routing area directorate, I have reviewed the | >> subject document. Here are my comments: | >> | >> Comments: | >> | >>   1. The last sentence of the abstract doesn't make sense. | >"Additionally, | >>      the information can be placed in LSPs that have TLVs as yet | >>      undefined, if this information is used to convey the same | >>      meaning in these future TLVs as it used in the currently defined | >>      TLVs". Suggested - "The administrative tag sub-TLVs may | >be used with | >>      with future TLVs as long as their semantics are preserved." | >> | >>   2. Section 5.2 - The value of the type is wrong - it | >should be 2 rather | >>      than 1. | >> | >>   3. Section 6 says the ordering of tags is not significant. | >However, the | >>      previous sections (5.1 and 5.2) say that an | >implementation may only | >>      consider the first tag. | >> | >>   4. Section 7 - List the requirements for receiving the new | >Sub-TLVs in | >>      this compliance section as well (even if they were stated | >> previously). | >> | >>   5. Section 8 - The example talks about R2 associating tag 110 with | >> property | >>      A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >1.1.1.0/24 with | >> property | >>      A is adjacent to R1 (which applies to me that R1 originate the | >> prefix). | >>      Please fix either the example or the figure. | >> | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >> | >>   1. The abstract contains references. The documents should | >be specified | >>      by name since the abstract can be excerpted. | >> | >>   2. Line 323 over 72 chars. | >> | >>     Line 323 length is 74 | >>          Routing in IS-IS", | >draft-ietf-isis-wg-multi-topology-03.txt, | >> April | >> | >>   3. Pages 2, 3, 4, and 5 have over 58 lines. | >> | > | > | >-- | >Acee | > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue May 27 19:02:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07938 for ; Tue, 27 May 2003 19:02:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RMvZB30438; Tue, 27 May 2003 18:57:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RMuVB30386 for ; Tue, 27 May 2003 18:56:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07762; Tue, 27 May 2003 18:56:23 -0400 (EDT) Message-Id: <200305272256.SAA07762@ietf.org> To: IETF-Announce: ; Cc: isis-wg@ietf.org From: The IESG Reply-to: iesg@ietf.org Subject: [Isis-wg] Last Call: Routing IPv6 with IS-IS to Informational Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 May 2003 18:56:23 -0400 The IESG has received a request from the IS-IS for IP Internets Working Group to consider Routing IPv6 with IS-IS as a Informational. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 17:55:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25550 for ; Wed, 28 May 2003 17:55:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SLpZB15625; Wed, 28 May 2003 17:51:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SLoUB15591 for ; Wed, 28 May 2003 17:50:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25483 for ; Wed, 28 May 2003 17:50:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L8mv-0000Vs-00 for isis-wg@ietf.org; Wed, 28 May 2003 17:48:49 -0400 Received: from mail.ipinfusion.com ([65.223.109.2] helo=giga) by ietf-mx with esmtp (Exim 4.12) id 19L8mv-0000Vo-00 for isis-wg@ietf.org; Wed, 28 May 2003 17:48:49 -0400 Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga with esmtp (Exim 3.35 #1 (Debian)) id 19L8oA-0001hQ-00 for ; Wed, 28 May 2003 14:50:06 -0700 Message-ID: <87add6kagh.wl@giga.kayz.org> From: Noguchi Kay To: isis-wg@ietf.org In-Reply-To: <200305272256.SAA07762@ietf.org> References: <200305272256.SAA07762@ietf.org> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 14:50:06 -0700 Hi all, Maybe I didn't follow the discussion correctly but let me ask you this. What is the reason we make IPv6 with IS-IS draft as an Informational draft, not a Standard draft? We already shipped softwares based on this draft and, at least, I didn't see any discussions about this on the mailing list. Thank you, kay At Tue, 27 May 2003 18:56:23 -0400, The IESG wrote: > > > The IESG has received a request from the IS-IS for IP Internets > Working Group to consider Routing IPv6 with IS-IS > as a Informational. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt > > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 18:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27917 for ; Wed, 28 May 2003 18:25:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMMBB17827; Wed, 28 May 2003 18:22:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMLSB17763 for ; Wed, 28 May 2003 18:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27759 for ; Wed, 28 May 2003 18:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9Gs-0000ox-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:19:47 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19L9Gs-0000nJ-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:19:46 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9592923C60; Wed, 28 May 2003 15:08:48 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4SMKqYB015270; Wed, 28 May 2003 15:20:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Message-ID: Thread-Topic: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Thread-Index: AcMlZpiGu9KCxOFiTBGczCERaqma6wAAKVcA From: "Tony Li" To: "Noguchi Kay" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SMLSB17764 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 15:20:52 -0700 Content-Transfer-Encoding: 8bit Same reason as always: we don't have change control over IS-IS and we don't want to give the impression that we do. We might be able to get away with it for this particular draft, but frankly, it doesn't make a lot of difference one way or another... Tony | -----Original Message----- | From: Noguchi Kay [mailto:kay@ipinfusion.com] | Sent: Wednesday, May 28, 2003 2:50 PM | To: isis-wg@ietf.org | Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS | to Informational | | | Hi all, | | Maybe I didn't follow the discussion correctly but let me | ask you this. | | What is the reason we make IPv6 with IS-IS draft as an | Informational draft, | not a Standard draft? | | We already shipped softwares based on this draft and, at | least, I didn't see | any discussions about this on the mailing list. | | Thank you, | | kay | | At Tue, 27 May 2003 18:56:23 -0400, | The IESG wrote: | > | > | > The IESG has received a request from the IS-IS for IP Internets | > Working Group to consider Routing IPv6 with IS-IS | > as a Informational. | > | > The IESG plans to make a decision in the next few weeks, | and solicits | > final comments on this action. Please send any comments to the | > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. | > | > Files can be obtained via | > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt | > | > | > | > | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 18:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28352 for ; Wed, 28 May 2003 18:48:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMk8B19385; Wed, 28 May 2003 18:46:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMjmB19363 for ; Wed, 28 May 2003 18:45:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28250 for ; Wed, 28 May 2003 18:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9eQ-0000u5-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:44:06 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19L9eP-0000u2-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:44:05 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4SMjAFW026194; Wed, 28 May 2003 15:45:10 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO03514; Wed, 28 May 2003 15:37:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20030528153646.03836448@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Tony Li" From: Les Ginsberg Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: "Noguchi Kay" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 15:45:08 -0700 At 03:20 PM 5/28/2003 -0700, Tony Li wrote: >Same reason as always: we don't have change control over IS-IS and >we don't want to give the impression that we do. We might be able >to get away with it for this particular draft, but frankly, it doesn't >make a lot of difference one way or another... Sooo..., what is the position of the WG on draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the IPV6 draft certainly COULD follow the standards track. Is the WG going to make a calculated decision as to which drafts are worth following the standards track and which aren't? Are we leaving it to the discretion of the author(s)? Or are we simply saying "Thanx very much Alex, but we don't really want to do this work ever?" Les >Tony > > >| -----Original Message----- >| From: Noguchi Kay [mailto:kay@ipinfusion.com] >| Sent: Wednesday, May 28, 2003 2:50 PM >| To: isis-wg@ietf.org >| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS >| to Informational >| >| >| Hi all, >| >| Maybe I didn't follow the discussion correctly but let me >| ask you this. >| >| What is the reason we make IPv6 with IS-IS draft as an >| Informational draft, >| not a Standard draft? >| >| We already shipped softwares based on this draft and, at >| least, I didn't see >| any discussions about this on the mailing list. >| >| Thank you, >| >| kay >| >| At Tue, 27 May 2003 18:56:23 -0400, >| The IESG wrote: >| > >| > >| > The IESG has received a request from the IS-IS for IP Internets >| > Working Group to consider Routing IPv6 with IS-IS >| > as a Informational. >| > >| > The IESG plans to make a decision in the next few weeks, >| and solicits >| > final comments on this action. Please send any comments to the >| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >| > >| > Files can be obtained via >| > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt >| > >| > >| > >| > >| _______________________________________________ >| Isis-wg mailing list >| Isis-wg@ietf.org >| https://www1.ietf.org/mailman/listinfo/isis-wg >| _______________________________________________ >| Isis-wg-external mailing list >| Isis-wg-external@mailist.procket.com >| http://mailist.procket.com/mailman/listinfo/isis-wg-external >| >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 18:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28625 for ; Wed, 28 May 2003 18:59:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMuBB19806; Wed, 28 May 2003 18:56:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SMtoB19788 for ; Wed, 28 May 2003 18:55:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28566 for ; Wed, 28 May 2003 18:55:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9o8-0000xp-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:54:08 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19L9o7-0000xg-00 for isis-wg@ietf.org; Wed, 28 May 2003 18:54:07 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 78B8623C61; Wed, 28 May 2003 15:43:11 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4SMtEYB016510; Wed, 28 May 2003 15:55:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Message-ID: Thread-Topic: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Thread-Index: AcMlave+jgrOyvx6Qt6F8fH6+THyPwAAPUJw From: "Tony Li" To: "Les Ginsberg" Cc: "Noguchi Kay" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SMtoB19789 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 15:55:14 -0700 Content-Transfer-Encoding: 8bit There is certainly more of a struggle to make it a 'Standard', so before anyone proposes to do it, I would suggest that we contemplate the upside. If any. OSPF is and will continue to be the official standard IGP of the IETF and trying to make IS-IS documents into standards will likely inflame the OSPF vs. IS-IS wars again. And tick off the ITU. Lotsa downside... Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@cisco.com] | Sent: Wednesday, May 28, 2003 3:45 PM | To: Tony Li | Cc: Noguchi Kay; isis-wg@ietf.org | Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with | IS-IS to Informational | | | At 03:20 PM 5/28/2003 -0700, Tony Li wrote: | | | >Same reason as always: we don't have change control over IS-IS and | >we don't want to give the impression that we do. We might be able | >to get away with it for this particular draft, but | frankly, it doesn't | >make a lot of difference one way or another... | | | Sooo..., what is the position of the WG on | draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the | IPV6 draft | certainly COULD follow the standards track. Is the WG | going to make a | calculated decision as to which drafts are worth following | the standards | track and which aren't? Are we leaving it to the discretion of the | author(s)? Or are we simply saying "Thanx very much Alex, | but we don't | really want to do this work ever?" | | Les | | | >Tony | > | > | >| -----Original Message----- | >| From: Noguchi Kay [mailto:kay@ipinfusion.com] | >| Sent: Wednesday, May 28, 2003 2:50 PM | >| To: isis-wg@ietf.org | >| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS | >| to Informational | >| | >| | >| Hi all, | >| | >| Maybe I didn't follow the discussion correctly but let me | >| ask you this. | >| | >| What is the reason we make IPv6 with IS-IS draft as an | >| Informational draft, | >| not a Standard draft? | >| | >| We already shipped softwares based on this draft and, at | >| least, I didn't see | >| any discussions about this on the mailing list. | >| | >| Thank you, | >| | >| | kay | >| | >| At Tue, 27 May 2003 18:56:23 -0400, | >| The IESG wrote: | >| > | >| > | >| > The IESG has received a request from the IS-IS for | IP Internets | >| > Working Group to consider Routing IPv6 with IS-IS | >| > as a Informational. | >| > | >| > The IESG plans to make a decision in the next few weeks, | >| and solicits | >| > final comments on this action. Please send any | comments to the | >| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. | >| > | >| > Files can be obtained via | >| > | http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 .txt >| > >| > >| > >| > >| _______________________________________________ >| Isis-wg mailing list >| Isis-wg@ietf.org >| https://www1.ietf.org/mailman/listinfo/isis-wg >| _______________________________________________ >| Isis-wg-external mailing list >| Isis-wg-external@mailist.procket.com >| http://mailist.procket.com/mailman/listinfo/isis-wg-external >| >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 19:06:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28966 for ; Wed, 28 May 2003 19:06:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SN3NB20106; Wed, 28 May 2003 19:03:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SN2TB20069 for ; Wed, 28 May 2003 19:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28844 for ; Wed, 28 May 2003 19:02:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9uZ-00012m-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:00:47 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19L9uY-00012d-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:00:46 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4SN1oFW011328; Wed, 28 May 2003 16:01:51 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-193.cisco.com [64.102.83.193]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACH39658; Wed, 28 May 2003 16:01:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20030528185855.01d82ed8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: Jeff Learman Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: "Tony Li" , "Noguchi Kay" , In-Reply-To: <4.3.2.7.2.20030528153646.03836448@mira-sjc5-3.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 19:01:48 -0400 Making this an informational document makes the distinction between IETF standards and informational documents meaningless. We are empowered to make standards for use on the Internet. They may involve doing things differently than specified for certain underlying non-IETF standards, but that has never stopped progress before and it shouldn't now. Regards, Jeff At 06:45 PM 5/28/2003, Les Ginsberg wrote: >At 03:20 PM 5/28/2003 -0700, Tony Li wrote: > > >>Same reason as always: we don't have change control over IS-IS and >>we don't want to give the impression that we do. We might be able >>to get away with it for this particular draft, but frankly, it doesn't >>make a lot of difference one way or another... > > >Sooo..., what is the position of the WG on draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the IPV6 draft certainly COULD follow the standards track. Is the WG going to make a calculated decision as to which drafts are worth following the standards track and which aren't? Are we leaving it to the discretion of the author(s)? Or are we simply saying "Thanx very much Alex, but we don't really want to do this work ever?" > > Les > > >>Tony >> >> >>| -----Original Message----- >>| From: Noguchi Kay [mailto:kay@ipinfusion.com] >>| Sent: Wednesday, May 28, 2003 2:50 PM >>| To: isis-wg@ietf.org >>| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS >>| to Informational >>| >>| >>| Hi all, >>| >>| Maybe I didn't follow the discussion correctly but let me >>| ask you this. >>| >>| What is the reason we make IPv6 with IS-IS draft as an >>| Informational draft, >>| not a Standard draft? >>| >>| We already shipped softwares based on this draft and, at >>| least, I didn't see >>| any discussions about this on the mailing list. >>| >>| Thank you, >>| >>| kay >>| >>| At Tue, 27 May 2003 18:56:23 -0400, >>| The IESG wrote: >>| > >>| > >>| > The IESG has received a request from the IS-IS for IP Internets >>| > Working Group to consider Routing IPv6 with IS-IS >>| > as a Informational. >>| > >>| > The IESG plans to make a decision in the next few weeks, >>| and solicits >>| > final comments on this action. Please send any comments to the >>| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >>| > >>| > Files can be obtained via >>| > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt >>| > >>| > >>| > >>| > >>| _______________________________________________ >>| Isis-wg mailing list >>| Isis-wg@ietf.org >>| https://www1.ietf.org/mailman/listinfo/isis-wg >>| _______________________________________________ >>| Isis-wg-external mailing list >>| Isis-wg-external@mailist.procket.com >>| http://mailist.procket.com/mailman/listinfo/isis-wg-external >>| >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 19:11:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29092 for ; Wed, 28 May 2003 19:11:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SN83B21116; Wed, 28 May 2003 19:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SN7OB20910 for ; Wed, 28 May 2003 19:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28994 for ; Wed, 28 May 2003 19:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9zJ-00014p-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:05:41 -0400 Received: from mail.ipinfusion.com ([65.223.109.2] helo=giga) by ietf-mx with esmtp (Exim 4.12) id 19L9zI-00014K-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:05:40 -0400 Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga with esmtp (Exim 3.35 #1 (Debian)) id 19LA0b-0001kU-00 for ; Wed, 28 May 2003 16:07:01 -0700 Message-ID: <878ysqk6wa.wl@giga.kayz.org> From: Noguchi Kay To: Subject: Re: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational In-Reply-To: References: X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 16:07:01 -0700 Hi Tony, > Same reason as always: we don't have change control over IS-IS and > we don't want to give the impression that we do. We might be able > to get away with it for this particular draft, but frankly, it doesn't > make a lot of difference one way or another... That's why we only have the informational RFCs in our group. I didn't notice all the RFCs we have are informational. Thank you, kay > Tony > > > | -----Original Message----- > | From: Noguchi Kay [mailto:kay@ipinfusion.com] > | Sent: Wednesday, May 28, 2003 2:50 PM > | To: isis-wg@ietf.org > | Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS > | to Informational > | > | > | Hi all, > | > | Maybe I didn't follow the discussion correctly but let me > | ask you this. > | > | What is the reason we make IPv6 with IS-IS draft as an > | Informational draft, > | not a Standard draft? > | > | We already shipped softwares based on this draft and, at > | least, I didn't see > | any discussions about this on the mailing list. > | > | Thank you, > | > | kay > | > | At Tue, 27 May 2003 18:56:23 -0400, > | The IESG wrote: > | > > | > > | > The IESG has received a request from the IS-IS for IP Internets > | > Working Group to consider Routing IPv6 with IS-IS > | > as a Informational. > | > > | > The IESG plans to make a decision in the next few weeks, > | and solicits > | > final comments on this action. Please send any comments to the > | > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > | > > | > Files can be obtained via > | > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt > | > > | > > | > > | > > | _______________________________________________ > | Isis-wg mailing list > | Isis-wg@ietf.org > | https://www1.ietf.org/mailman/listinfo/isis-wg > | _______________________________________________ > | Isis-wg-external mailing list > | Isis-wg-external@mailist.procket.com > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > | > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 19:32:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29854 for ; Wed, 28 May 2003 19:32:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SNT8B21771; Wed, 28 May 2003 19:29:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SNSXB21754 for ; Wed, 28 May 2003 19:28:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29504 for ; Wed, 28 May 2003 19:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAJn-0001C6-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:26:51 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19LAJm-0001Bk-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:26:50 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 1619823C66; Wed, 28 May 2003 16:15:52 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4SNRuYB017633; Wed, 28 May 2003 16:27:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Message-ID: Thread-Topic: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Thread-Index: AcMlbToUNtBiAs9+T5GG6kNXj0LnxQAApgFA From: "Tony Li" To: "Jeff Learman" , "Les Ginsberg" Cc: "Noguchi Kay" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SNSXB21755 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 16:27:56 -0700 Content-Transfer-Encoding: 8bit Jeff, The market decided a long time ago that the notion of an IETF 'standard' was pretty nebulous at best. The market decides what of our work is important. The last document that the IETF needed to make a 'standard' so that everyone would implement it was RFC 791. Since then, there haven't been a whole lot of really important RFCs. Tony p.s. I sure hope our real charter is to help make technical contributions. If our sole purpose is to write standards, then we're working too hard and we should write more standards for IP over letter carriers, etc. | -----Original Message----- | From: Jeff Learman [mailto:jlearman@cisco.com] | Sent: Wednesday, May 28, 2003 4:02 PM | To: Les Ginsberg | Cc: Tony Li; Noguchi Kay; isis-wg@ietf.org | Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with | IS-IS to Informational | | | | Making this an informational document makes the distinction between | IETF standards and informational documents meaningless. We are | empowered to make standards for use on the Internet. They may | involve doing things differently than specified for certain | underlying non-IETF standards, but that has never stopped | progress before and it shouldn't now. | | Regards, | Jeff | | At 06:45 PM 5/28/2003, Les Ginsberg wrote: | >At 03:20 PM 5/28/2003 -0700, Tony Li wrote: | > | > | >>Same reason as always: we don't have change control over | IS-IS and | >>we don't want to give the impression that we do. We | might be able | >>to get away with it for this particular draft, but | frankly, it doesn't | >>make a lot of difference one way or another... | > | > | >Sooo..., what is the position of the WG on | draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the | IPV6 draft certainly COULD follow the standards track. Is | the WG going to make a calculated decision as to which | drafts are worth following the standards track and which | aren't? Are we leaving it to the discretion of the | author(s)? Or are we simply saying "Thanx very much Alex, | but we don't really want to do this work ever?" | > | > Les | > | > | >>Tony | >> | >> | >>| -----Original Message----- | >>| From: Noguchi Kay [mailto:kay@ipinfusion.com] | >>| Sent: Wednesday, May 28, 2003 2:50 PM | >>| To: isis-wg@ietf.org | >>| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS | >>| to Informational | >>| | >>| | >>| Hi all, | >>| | >>| Maybe I didn't follow the discussion correctly but let me | >>| ask you this. | >>| | >>| What is the reason we make IPv6 with IS-IS draft as an | >>| Informational draft, | >>| not a Standard draft? | >>| | >>| We already shipped softwares based on this draft and, at | >>| least, I didn't see | >>| any discussions about this on the mailing list. | >>| | >>| Thank you, | >>| | >>| | kay | >>| | >>| At Tue, 27 May 2003 18:56:23 -0400, | >>| The IESG wrote: | >>| > | >>| > | >>| > The IESG has received a request from the IS-IS | for IP Internets | >>| > Working Group to consider Routing IPv6 with IS-IS | >>| > as a Informational. | >>| > | >>| > The IESG plans to make a decision in the next few weeks, | >>| and solicits | >>| > final comments on this action. Please send any | comments to the | >>| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. | >>| > | >>| > Files can be obtained via | >>| > | http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 .txt >>| > >>| > >>| > >>| > >>| _______________________________________________ >>| Isis-wg mailing list >>| Isis-wg@ietf.org >>| https://www1.ietf.org/mailman/listinfo/isis-wg >>| _______________________________________________ >>| Isis-wg-external mailing list >>| Isis-wg-external@mailist.procket.com >>| http://mailist.procket.com/mailman/listinfo/isis-wg-external >>| >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed May 28 20:12:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00748 for ; Wed, 28 May 2003 20:12:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T01NB23655; Wed, 28 May 2003 20:01:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T00ZB23595 for ; Wed, 28 May 2003 20:00:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00419 for ; Wed, 28 May 2003 20:00:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAoq-0001Qu-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:58:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19LAop-0001Qr-00 for isis-wg@ietf.org; Wed, 28 May 2003 19:58:55 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4T000FW022471; Wed, 28 May 2003 17:00:00 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO10924; Wed, 28 May 2003 16:52:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20030528164851.03840808@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Tony Li" From: Les Ginsberg Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational Cc: "Noguchi Kay" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 16:59:50 -0700 At 03:55 PM 5/28/2003 -0700, Tony Li wrote: >There is certainly more of a struggle to make it a 'Standard', so >before anyone proposes to do it, I would suggest that we contemplate >the upside. If any. > >OSPF is and will continue to be the official standard IGP of the >IETF and trying to make IS-IS documents into standards will likely >inflame the OSPF vs. IS-IS wars again. And tick off the ITU. Well, I thought that one of the significant motivations for Alex's draft was the fact that the ITU wanted to use IETF IS-IS extensions, but needed them to be standards track documents in order to do so. So I don't see why the ITU would be ticked off. Rather I would expect the ITU would be disappointed that the WG has decided not to standards track extensions that have uses in the ITU world. This means that in order to use the extensions they will have to create their own versions of the extensions (as they already have done with 3-way) and we will have to hope that they are compatible and remain so. As for the OSPF folks, I don't see why they would care. We are not marketing the protocol - we are just responding to the needs of the user community and trying to provide interoperability. Les >Lotsa downside... > >Tony > > >| -----Original Message----- >| From: Les Ginsberg [mailto:ginsberg@cisco.com] >| Sent: Wednesday, May 28, 2003 3:45 PM >| To: Tony Li >| Cc: Noguchi Kay; isis-wg@ietf.org >| Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with >| IS-IS to Informational >| >| >| At 03:20 PM 5/28/2003 -0700, Tony Li wrote: >| >| >| >Same reason as always: we don't have change control over IS-IS and >| >we don't want to give the impression that we do. We might be able >| >to get away with it for this particular draft, but >| frankly, it doesn't >| >make a lot of difference one way or another... >| >| >| Sooo..., what is the position of the WG on >| draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the >| IPV6 draft >| certainly COULD follow the standards track. Is the WG >| going to make a >| calculated decision as to which drafts are worth following >| the standards >| track and which aren't? Are we leaving it to the discretion of the >| author(s)? Or are we simply saying "Thanx very much Alex, >| but we don't >| really want to do this work ever?" >| >| Les >| >| >| >Tony >| > >| > >| >| -----Original Message----- >| >| From: Noguchi Kay [mailto:kay@ipinfusion.com] >| >| Sent: Wednesday, May 28, 2003 2:50 PM >| >| To: isis-wg@ietf.org >| >| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS >| >| to Informational >| >| >| >| >| >| Hi all, >| >| >| >| Maybe I didn't follow the discussion correctly but let me >| >| ask you this. >| >| >| >| What is the reason we make IPv6 with IS-IS draft as an >| >| Informational draft, >| >| not a Standard draft? >| >| >| >| We already shipped softwares based on this draft and, at >| >| least, I didn't see >| >| any discussions about this on the mailing list. >| >| >| >| Thank you, >| >| >| >| >| kay >| >| >| >| At Tue, 27 May 2003 18:56:23 -0400, >| >| The IESG wrote: >| >| > >| >| > >| >| > The IESG has received a request from the IS-IS for >| IP Internets >| >| > Working Group to consider Routing IPv6 with IS-IS >| >| > as a Informational. >| >| > >| >| > The IESG plans to make a decision in the next few weeks, >| >| and solicits >| >| > final comments on this action. Please send any >| comments to the >| >| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >| >| > >| >| > Files can be obtained via >| >| > >| http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 >.txt > >| > > >| > > >| > > >| > > >| _______________________________________________ > >| Isis-wg mailing list > >| Isis-wg@ietf.org > >| https://www1.ietf.org/mailman/listinfo/isis-wg > >| _______________________________________________ > >| Isis-wg-external mailing list > >| Isis-wg-external@mailist.procket.com > >| http://mailist.procket.com/mailman/listinfo/isis-wg-external > >| > >_______________________________________________ > >Isis-wg mailing list > >Isis-wg@ietf.org > >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 29 08:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00308 for ; Thu, 29 May 2003 08:18:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCFKB16643; Thu, 29 May 2003 08:15:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCEfB16587 for ; Thu, 29 May 2003 08:14:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00209 for ; Thu, 29 May 2003 08:14:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LMHF-0006Sc-00 for isis-wg@ietf.org; Thu, 29 May 2003 08:13:01 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19LMHF-0006SZ-00 for isis-wg@ietf.org; Thu, 29 May 2003 08:13:01 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h4TCEcep004266 for ; Thu, 29 May 2003 05:14:38 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h4TCEaM2011428 for ; Thu, 29 May 2003 07:14:37 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 May 2003 08:14:20 -0400 Message-ID: From: "Jonnala, Nagi" To: isis-wg@ietf.org Cc: ISIS_Hyderabad , "Alluru, GopalaRaju" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Overloaded DIS problems Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 May 2003 08:16:14 -0400 All, We have a LAN having 10 routers. After sometime for some reason, the DIS gets *overloaded* and cannot forward the PDUs. Since the DIS is overloaded, as per the 7.2.8.1 section of ISO-10589 document, the decision process(es) of a router(s) has no alternative but to drop the pseudo node LSP. Hence no route is calculated to any of the neighbors in the LAN (Obviously no route to other segments of the network). To be specific, technically you can ONLY have End system neighbors(Connected IP routes) reachabilities of the DIS even though all other routers are connected directly. The major concern is if you have one router gone bad, should you allow a whole bunch of others non-functional? I'm aware that sys-ad can change the DIS priority on another router and make things work. But shouldn't protocol take care of that case? The second problem is - overloaded DIS anyway cannot do its flooding job properly and there is always a possibility of all sorts of issues. If we know that DIS can't do a proper job, can't we make him resign from the job, provided there is backward compatibility and a simpler solution is available. I think it is a considerable issue to be addressed by the group. I can think of a simpler solution but before digging into the solution space I would like to receive group's response on the problem. Let me know if we are not in sync. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 29 09:19:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02590 for ; Thu, 29 May 2003 09:19:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TDGQB21006; Thu, 29 May 2003 09:16:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TDG0B20984 for ; Thu, 29 May 2003 09:16:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02414 for ; Thu, 29 May 2003 09:15:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LNEY-00071r-00 for isis-wg@ietf.org; Thu, 29 May 2003 09:14:19 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19LNEY-00071m-00 for isis-wg@ietf.org; Thu, 29 May 2003 09:14:18 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4TDFM9x006037; Thu, 29 May 2003 06:15:23 -0700 (PDT) Received: from mshand-w2k.cisco.com (dhcp-rea-gp250-64-103-64-161.cisco.com [64.103.64.161]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA11100; Thu, 29 May 2003 14:15:21 +0100 (BST) Message-Id: <4.3.2.7.2.20030529133350.04be6d10@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jonnala, Nagi" From: mike shand Subject: Re: [Isis-wg] Overloaded DIS problems Cc: isis-wg@ietf.org, ISIS_Hyderabad , "Alluru, GopalaRaju" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 May 2003 14:15:16 +0100 At 08:16 29/05/2003 -0400, Jonnala, Nagi wrote: >All, > >We have a LAN having 10 routers. After sometime for some reason, >the DIS gets *overloaded* and cannot forward the PDUs. I think you have a misunderstanding of what is meant by "overloaded". "Overloaded" in this context means that a router is unable to store the entire LSP database (and therefore any routes which it computes are likely to be wrong). It does NOT mean that it has failed in some way. If it has failed it should really be taking itself out of the network (perhaps by setting a zero holding time on its hellos). Merely setting the "LSP database overload" bit is not necessarily enough. If it has enough smarts to set the overload bit, then it has enough smarts to take itself out. Are you saying that the DIS is setting the overload bit for the wrong reason? (See 7.3.19) I'm a little concerned that you seem to imply that the overload bit is being set in the pseudonode LSP. There is no reason to do this, since routes computed "through" the pseudonode, do not (in general) require forwarding by the DIS. I don't believe you will find anywhere in ISO/IEC 10589 which requires the setting of the overload bit in the pseudonode LSP. In general the setting of the overload bit is a strategy of last resort designed to allow the network to recover when the temporary condition which caused it goes away (for example accidental area merge). If it is the case that one router on a LAN has a much lower LSP storage capacity, then it might be an idea to set that with a lower priority of being DIS. Overload is something which should never occur in a well designed network. (Of course the overload bit may be set for other reasons such as BGP synchronization, but that is a different issue). Mike >Since the DIS is overloaded, as per the 7.2.8.1 section of ISO-10589 >document, >the decision process(es) of a router(s) has no alternative but to drop the >pseudo node LSP. Hence no route is calculated to any of the neighbors in the > >LAN (Obviously no route to other segments of the network). To be specific, >technically you can ONLY have End system neighbors(Connected IP routes) >reachabilities of the DIS even though all other routers are connected >directly. > >The major concern is if you have one router gone bad, should you allow a >whole bunch >of others non-functional? I'm aware that sys-ad can change the DIS priority >on >another router and make things work. But shouldn't protocol take care of >that case? > >The second problem is - overloaded DIS anyway cannot do its flooding job >properly >and there is always a possibility of all sorts of issues. If we know that >DIS >can't do a proper job, can't we make him resign from the job, provided >there is >backward compatibility and a simpler solution is available. > >I think it is a considerable issue to be addressed by the group. I can think > >of a simpler solution but before digging into the solution space I would >like to receive >group's response on the problem. > >Let me know if we are not in sync. > >Thanks >Nagi. > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 29 12:33:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09461 for ; Thu, 29 May 2003 12:33:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGQVB02000; Thu, 29 May 2003 12:26:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGPqB01955 for ; Thu, 29 May 2003 12:25:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09120 for ; Thu, 29 May 2003 12:25:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQCK-0000Tz-00 for isis-wg@ietf.org; Thu, 29 May 2003 12:24:12 -0400 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 19LQCJ-0000Tj-00 for isis-wg@ietf.org; Thu, 29 May 2003 12:24:11 -0400 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id ; Thu, 29 May 2003 12:25:14 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB3503E28A09@entmail.gnilink.com> From: "Martin, Christian" To: "'Tony Li'" , Les Ginsberg Cc: Noguchi Kay , isis-wg@ietf.org Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informat ional MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C325FE.E226CB60" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 May 2003 12:25:14 -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_01C325FE.E226CB60 Content-Type: text/plain Les, Tony, I agree that attempting to drive IS-IS toward IETF standardization may be problematic for the reasons stated. However, the future of IS-IS may (or may not) in fact hinge on its 'candidacy' for standardization, in that, as corporations become increasingly concerned about things like security and interoperability, they appear to be correspondingly concerned with things like standardization or standardizability (sp?). Does anyone foresee IS-IS's current lack of standardization as something that will or may diminish its value over time? For example, in a future where IPv6 may dominate the address structure of the Internet, will conservative providers consider shifting to OSPFv3 out of a perception that it will have perhaps greater longevity? I know this doesn't seeem to be the pragmatic direction that many will take, but things like the ability to encrypt OSPF data may start to become a requirement from a business-level or even government-level perspective. I can envision federal RFPs that require ISPs to encrypt all routing data on their networks. Savvy security experts will scoff at HMAC-MD5 in IS-IS as substandard to this requirement, and may direct their clients or companies to choose providers that do OSPFv3 with IPSEC, for example. Just a thought. Regards, Chris >-----Original Message----- >From: Tony Li [mailto:Tony.Li@procket.com] >Sent: Wednesday, May 28, 2003 6:55 PM >To: Les Ginsberg >Cc: Noguchi Kay; isis-wg@ietf.org >Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS >to Informational > > > >There is certainly more of a struggle to make it a 'Standard', >so before anyone proposes to do it, I would suggest that we >contemplate the upside. If any. > >OSPF is and will continue to be the official standard IGP of >the IETF and trying to make IS-IS documents into standards >will likely inflame the OSPF vs. IS-IS wars again. And tick >off the ITU. > >Lotsa downside... > >Tony > > >| -----Original Message----- >| From: Les Ginsberg [mailto:ginsberg@cisco.com] >| Sent: Wednesday, May 28, 2003 3:45 PM >| To: Tony Li >| Cc: Noguchi Kay; isis-wg@ietf.org >| Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with >| IS-IS to Informational >| >| >| At 03:20 PM 5/28/2003 -0700, Tony Li wrote: >| >| >| >Same reason as always: we don't have change control over >IS-IS and >| >we don't want to give the impression that we do. We >might be able >| >to get away with it for this particular draft, but >| frankly, it doesn't >| >make a lot of difference one way or another... >| >| >| Sooo..., what is the position of the WG on >| draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the >| IPV6 draft >| certainly COULD follow the standards track. Is the WG >| going to make a >| calculated decision as to which drafts are worth following >| the standards >| track and which aren't? Are we leaving it to the >discretion of the >| author(s)? Or are we simply saying "Thanx very much Alex, >| but we don't >| really want to do this work ever?" >| >| Les >| >| >| >Tony >| > >| > >| >| -----Original Message----- >| >| From: Noguchi Kay [mailto:kay@ipinfusion.com] >| >| Sent: Wednesday, May 28, 2003 2:50 PM >| >| To: isis-wg@ietf.org >| >| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS >| >| to Informational >| >| >| >| >| >| Hi all, >| >| >| >| Maybe I didn't follow the discussion correctly but let me >| >| ask you this. >| >| >| >| What is the reason we make IPv6 with IS-IS draft as an >| >| Informational draft, >| >| not a Standard draft? >| >| >| >| We already shipped softwares based on this draft and, at >| >| least, I didn't see >| >| any discussions about this on the mailing list. >| >| >| >| Thank you, >| >| >| >| >| kay >| >| >| >| At Tue, 27 May 2003 18:56:23 -0400, >| >| The IESG wrote: >| >| > >| >| > >| >| > The IESG has received a request from the IS-IS for >| IP Internets >| >| > Working Group to consider Routing IPv6 with IS-IS >| >| > as a Informational. >| >| > >| >| > The IESG plans to make a decision in the next few weeks, >| >| and solicits >| >| > final comments on this action. Please send any >| comments to the >| >| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >| >| > >| >| > Files can be obtained via >| >| > >| http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 >.txt >>| > >>| > >>| > >>| > >>| _______________________________________________ >>| Isis-wg mailing list >>| Isis-wg@ietf.org >>| https://www1.ietf.org/mailman/listinfo/isis-wg >>| _______________________________________________ >>| Isis-wg-external mailing list >>| Isis-wg-external@mailist.procket.com >>| http://mailist.procket.com/mailman/listinfo/isis-wg-external >>| >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > ------_=_NextPart_001_01C325FE.E226CB60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to = Informational

Les, Tony,

I agree that attempting to drive IS-IS toward IETF = standardization may be problematic for the reasons stated.  = However, the future of IS-IS may (or may not) in fact hinge on its = 'candidacy' for standardization, in that, as corporations become = increasingly concerned about things like security and interoperability, = they appear to be correspondingly concerned with things like = standardization or standardizability (sp?).  Does anyone foresee = IS-IS's current lack of standardization as something that will or may = diminish its value over time?  For example, in a future where IPv6 = may dominate the address structure of the Internet, will conservative = providers consider shifting to OSPFv3 out of a perception that it will = have perhaps greater longevity?  I know this doesn't seeem to be = the pragmatic direction that many will take, but things like the = ability to encrypt OSPF data may start to become a requirement from a = business-level or even government-level perspective.  I can = envision federal RFPs that require ISPs to encrypt all routing data on = their networks.  Savvy security experts will scoff at HMAC-MD5 in = IS-IS as substandard to this requirement, and may direct their clients = or companies to choose providers that do OSPFv3 with IPSEC, for = example.

Just a thought.

Regards,
Chris


>-----Original Message-----
>From: Tony Li [mailto:Tony.Li@procket.com] =
>Sent: Wednesday, May 28, 2003 6:55 PM
>To: Les Ginsberg
>Cc: Noguchi Kay; isis-wg@ietf.org
>Subject: RE: [Isis-wg] Re: Last Call: Routing = IPv6 with IS-IS
>to Informational
>
>
>
>There is certainly more of a struggle to make it = a 'Standard',
>so before anyone proposes to do it, I would = suggest that we
>contemplate the upside.  If any.
>
>OSPF is and will continue to be the official = standard IGP of
>the IETF and trying to make IS-IS documents into = standards
>will likely inflame the OSPF vs. IS-IS wars = again.  And tick
>off the ITU.
>
>Lotsa downside...
>
>Tony
>
>
>|    -----Original = Message-----
>|    From: Les Ginsberg [mailto:ginsberg@cisco.com] =
>|    Sent: Wednesday, May 28, = 2003 3:45 PM
>|    To: Tony Li
>|    Cc: Noguchi Kay; = isis-wg@ietf.org
>|    Subject: RE: [Isis-wg] Re: = Last Call: Routing IPv6 with
>|    IS-IS to = Informational
>|   
>|   
>|    At 03:20 PM 5/28/2003 -0700, = Tony Li wrote:
>|   
>|   
>|    >Same reason as always: = we don't have change control over
>IS-IS and
>|    >we don't want to give = the impression that we do.  We
>might be able
>|    >to get away with it for = this particular draft, but
>|    frankly, it doesn't
>|    >make a lot of difference = one way or another...
>|   
>|   
>|    Sooo..., what is the = position of the WG on
>|    = draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the
>|    IPV6 draft
>|    certainly COULD follow the = standards track. Is the WG
>|    going to make a
>|    calculated decision as to = which drafts are worth following
>|    the standards
>|    track and which aren't? Are = we leaving it to the
>discretion of the
>|    author(s)? Or are we simply = saying "Thanx very much Alex,
>|    but we don't
>|    really want to do this work = ever?"
>|   
>|        = Les
>|   
>|   
>|    >Tony
>|    >
>|    >
>|    >|    = -----Original Message-----
>|    >|    = From: Noguchi Kay [mailto:kay@ipinfusion.com]=
>|    >|    = Sent: Wednesday, May 28, 2003 2:50 PM
>|    >|    To: = isis-wg@ietf.org
>|    >|    = Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS
>|    >|    to = Informational
>|    >|
>|    >|
>|    >|    Hi = all,
>|    >|
>|    >|    = Maybe I didn't follow the discussion correctly but let me
>|    >|    ask = you this.
>|    >|
>|    >|    What = is the reason we make IPv6 with IS-IS draft as an
>|    >|    = Informational draft,
>|    >|    not = a Standard draft?
>|    >|
>|    >|    We = already shipped softwares based on this draft and, at
>|    >|    = least, I didn't see
>|    >|    any = discussions about this on the mailing list.
>|    >|
>|    >|    = Thank you,
>|    >|
>|    = >|           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;        
>|          = kay
>|    >|
>|    >|    At = Tue, 27 May 2003 18:56:23 -0400,
>|    >|    The = IESG wrote:
>|    >|    = >
>|    >|    = >
>|    >|    > = The IESG has received a request from the IS-IS for
>|    IP Internets
>|    >|    > = Working Group to consider Routing IPv6 with IS-IS
>|    >|    > = <draft-ietf-isis-ipv6-05.txt> as a Informational.
>|    >|    = >
>|    >|    > = The IESG plans to make a decision in the next few weeks,
>|    >|    and = solicits
>|    >|    > = final comments on this action.  Please send any
>|    comments to the
>|    >|    > = iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10.
>|    >|    = >
>|    >|    > = Files can be obtained via
>|    >|    > =
>|    http://www.ietf.org/internet-drafts/draft-ietf-isis-ip= v6-05
>.txt
>>|    >
>>|    >
>>|    >
>>|    >
>>|    = _______________________________________________
>>|    Isis-wg mailing = list
>>|    Isis-wg@ietf.org
>>|    https://www1.ietf.org/mailman/listinfo/isis-wg
>>|    = _______________________________________________
>>|    Isis-wg-external mailing = list
>>|    = Isis-wg-external@mailist.procket.com
>>|    http://mailist.procket.com/mailman/listinfo/isis-wg-ex= ternal
>>|
>>_______________________________________________
>>Isis-wg mailing list
>>Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01C325FE.E226CB60-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu May 29 12:42:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09663 for ; Thu, 29 May 2003 12:42:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGd6B03700; Thu, 29 May 2003 12:39:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGcCB03643 for ; Thu, 29 May 2003 12:38:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09573 for ; Thu, 29 May 2003 12:38:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQOF-0000aU-00 for isis-wg@ietf.org; Thu, 29 May 2003 12:36:31 -0400 Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx with esmtp (Exim 4.12) id 19LQOE-0000aJ-00 for isis-wg@ietf.org; Thu, 29 May 2003 12:36:30 -0400 Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADT28777; Thu, 29 May 2003 11:37:38 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-21.hq.tellabs.com [172.23.111.21]) by mailw02.hq.tellabs.com with ESMTP (8.11.1/8.7.1) id h4TGbd715005; Thu, 29 May 2003 11:37:39 -0500 (CDT) Message-ID: <3ED63750.15785E80@tellabs.com> From: Jonathan Sadler X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li CC: Les Ginsberg , Noguchi Kay , isis-wg@ietf.org Subject: Re: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS to Informational References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx4.tellabs.com Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 May 2003 11:37:36 -0500 Content-Transfer-Encoding: 7bit > There is certainly more of a struggle to make it a 'Standard', so > before anyone proposes to do it, I would suggest that we contemplate > the upside. If any. > > OSPF is and will continue to be the official standard IGP of the > IETF and trying to make IS-IS documents into standards will likely > inflame the OSPF vs. IS-IS wars again. And tick off the ITU. I assume you mean "tick off JTC1 (ISO/IEC)". The ITU is not involved in the specification of IS-IS. However, since the ITU is a "user" of IS-IS, it is more likely to become "ticked off" if the IS-IS work in the IETF continues to be done as Informational RFCs. This is comes from the fact that Informational RFCs, according to the IETF, are not standards. This results in the ITU not being able to use them as normative references in an ITU standard. The result is the ITU may need to include a "paraphrased" version (due to RFC copyright restrictions) of the IETF Informational RFC in an ITU standard. An example where this has already taken place can be found in G.7712, where RFC 2966 is paraphrased. Unfortunately, such parapharsing can lead to (hopefully unintentionally) different "specifications" for how an extension is done. Consequently, there is benefit to the ITU by this document being on the "standrads track". Jonathan Sadler > Lotsa downside... > > Tony > > | -----Original Message----- > | From: Les Ginsberg [mailto:ginsberg@cisco.com] > | Sent: Wednesday, May 28, 2003 3:45 PM > | To: Tony Li > | Cc: Noguchi Kay; isis-wg@ietf.org > | Subject: RE: [Isis-wg] Re: Last Call: Routing IPv6 with > | IS-IS to Informational > | > | > | At 03:20 PM 5/28/2003 -0700, Tony Li wrote: > | > | > | >Same reason as always: we don't have change control over IS-IS and > | >we don't want to give the impression that we do. We might be able > | >to get away with it for this particular draft, but > | frankly, it doesn't > | >make a lot of difference one way or another... > | > | > | Sooo..., what is the position of the WG on > | draft-zinin-ietf-jtc1-aggr-01.txt?? Under Section 3.1 the > | IPV6 draft > | certainly COULD follow the standards track. Is the WG > | going to make a > | calculated decision as to which drafts are worth following > | the standards > | track and which aren't? Are we leaving it to the discretion of the > | author(s)? Or are we simply saying "Thanx very much Alex, > | but we don't > | really want to do this work ever?" > | > | Les > | > | > | >Tony > | > > | > > | >| -----Original Message----- > | >| From: Noguchi Kay [mailto:kay@ipinfusion.com] > | >| Sent: Wednesday, May 28, 2003 2:50 PM > | >| To: isis-wg@ietf.org > | >| Subject: [Isis-wg] Re: Last Call: Routing IPv6 with IS-IS > | >| to Informational > | >| > | >| > | >| Hi all, > | >| > | >| Maybe I didn't follow the discussion correctly but let me > | >| ask you this. > | >| > | >| What is the reason we make IPv6 with IS-IS draft as an > | >| Informational draft, > | >| not a Standard draft? > | >| > | >| We already shipped softwares based on this draft and, at > | >| least, I didn't see > | >| any discussions about this on the mailing list. > | >| > | >| Thank you, > | >| > | >| > | kay > | >| > | >| At Tue, 27 May 2003 18:56:23 -0400, > | >| The IESG wrote: > | >| > > | >| > > | >| > The IESG has received a request from the IS-IS for > | IP Internets > | >| > Working Group to consider Routing IPv6 with IS-IS > | >| > as a Informational. > | >| > > | >| > The IESG plans to make a decision in the next few weeks, > | >| and solicits > | >| > final comments on this action. Please send any > | comments to the > | >| > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > | >| > > | >| > Files can be obtained via > | >| > > | http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05 > .txt > >| > > >| > > >| > > >| > > >| _______________________________________________ > >| Isis-wg mailing list > >| Isis-wg@ietf.org > >| https://www1.ietf.org/mailman/listinfo/isis-wg > >| _______________________________________________ > >| Isis-wg-external mailing list > >| Isis-wg-external@mailist.procket.com > >| http://mailist.procket.com/mailman/listinfo/isis-wg-external > >| > >_______________________________________________ > >Isis-wg mailing list > >Isis-wg@ietf.org > >https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 30 12:49:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16455 for ; Fri, 30 May 2003 12:49:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UGiZB19209; Fri, 30 May 2003 12:44:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UGh9B19105 for ; Fri, 30 May 2003 12:43:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15882; Fri, 30 May 2003 12:43:01 -0400 (EDT) Message-Id: <200305301643.MAA15882@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , isis-wg@ietf.org From: The IESG Subject: [Isis-wg] Document Action: IS-IS Cryptographic Authentication to Informational Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 May 2003 12:43:01 -0400 The IESG has approved the Internet-Draft 'IS-IS Cryptographic Authentication' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. Technical Summary This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO 10589 and RFC 1142, with extensions to support IPv4 described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. Working Group Summary The draft documents a widely deployed mechanism. Changes to the authentication mechanism described here (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at some length, but ultimately were rejected. The mechanism here was already widely implemented in 1999. As of this writing, this mechanism is fairly widely deployed within the users interested in cryptographic authentication of IS-IS. The improvement provided by the proposed revised mechanism was not large enough to justify the change, given the installed base and lack of operator interest in deploying the proposed revised mechanism. Protocol Quality This specification was reviewed for IESG by Alex Zinin. RFC Editor Note Section "NORMATIVE REFERENCES" OLD: [1] ISO, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589 [Also republished as RFC 1142]. NEW: [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition." _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri May 30 18:35:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01896 for ; Fri, 30 May 2003 18:35:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMVDB12396; Fri, 30 May 2003 18:31:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMU1B12292 for ; Fri, 30 May 2003 18:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01793; Fri, 30 May 2003 18:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LsMB-0002Do-00; Fri, 30 May 2003 18:28:15 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19LsM9-0002DL-00; Fri, 30 May 2003 18:28:13 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h4UMT3f11604; Sat, 31 May 2003 00:29:03 +0200 From: Hannes Gredler To: Acee Lindem Cc: "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030530222903.GA11581@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED679BC.4060307@redback.com> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 31 May 2003 00:29:03 +0200 acee, our implementation currently support two tags and we pass it on in a ordered way for internal policy-processing e.g. first tag found is copied to the variable "tag" and the second tag is copied to the variable "tag2"; both variables can be matched against in our internal policy processing language; and thats IMHO the only place where the draft needs to be more specific: how an implementation [order, etc.] maps IS-IS-tags to match-clauses in the local policy processor; i am unsure about the ordering and number of supported tags of other implementations; stefano, can you shed some light ? --- SHOULD is IMO a bit too strong wording, i'd be happy with something like "MAY have more than one tag" /hannes On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: | Hannes, | | If we agree that having a single 32 bit and/or 64 bit tag is a | good idea then perhaps we could change the wording of the draft to | say that an implementation SHOULD only send and interpret a single | tag and SHOULD ignore data past the first tag. This would allow | the usage of multiple tags to be gracefully deprecated. | | If this isn't acceptable then can we can agree on a small | finite/known number of tags with suggested usage? | | Thanks, | Acee | | Hannes Gredler wrote: | >pls, keep in mind that there is already code in production that allows | >more than one tag; | > | >common use i have seen so far is | > | >tag #1 controls L2L1 leakage | >tag #2 for informational purposes and points to the area of origin; | > | >/hannes | > | >On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | >| RE: Comments on | >| | >| Acee, | >| | >| As the original goal was to create a capability similar to OSPF's route | >tag, | >| it may be wise to drop this capability. On the otherhand, having | >multiple | >| tags per route can provide more information about the route than a single | >| tag. In this regard, the 32 bit tag operates more like a community, and | >the | >| 64 bit tag operates like an extended community. From an implementation | >| perspective, the same routines for matching and setting these fields | >should | >| be similar to the community fields in BGP. | >| | >| I would like to solicit the WG for comments on which capability is most | >| attractive. The goal is not to introduce too much bloat (is it too late | >for | >| that?!) while still providing some flexibility. | >| | >| As soon as I receive any final comments, I will release the updated | >draft. | >| | >| Thanks for pointing out this critical piece! | >| | >| Regards, | >| chris | >| | >| >-----Original Message----- | >| >From: Acee Lindem [mailto:acee@redback.com] | >| >Sent: Friday, May 23, 2003 1:50 PM | >| >To: Acee Lindem | >| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >| >Directorate | >| >Subject: Re: Comments on | >| > | >| > | >| >Christian, Stefano, Brad, | >| > | >| >The follow-up discussion on the necessity for both 32 bit and | >| >64 bit tags raises the question as to whether or not it is | >| >wise to allow an arbitrary number of tags to be advertised. | >| > | >| > This draft proposes 2 new "Administrative Tag" sub-TLVs | >| >to be added | >| > to TLV 135 and 235. These TLVs specify one or more | >| >ordered, 32 or 64 | >| > ~~~~~~~~~~~~~~~ | >| > bit unsigned integers that may be associated with an IP prefix. | >| > | >| >However, the receiver need only use the first. | >| > | >| > An implementation may consider only one of the encoded | >| >tags, in which | >| > case the first encoded tag must be considered. A tag | >| >value of zero | >| > is reserved and should be treated as "no tag". | >| > | >| >IMHO, allowing an arbitrary number of tags affords more | >| >potential for interoperability and deviant applications than | >| >the 64 bit tag. | >| > | >| > | >| > | >| > | >| > | >| >Acee Lindem wrote: | >| >> As a member of the routing area directorate, I have reviewed the | >| >> subject document. Here are my comments: | >| >> | >| >> Comments: | >| >> | >| >> 1. The last sentence of the abstract doesn't make sense. | >| >"Additionally, | >| >> the information can be placed in LSPs that have TLVs as yet | >| >> undefined, if this information is used to convey the same | >| >> meaning in these future TLVs as it used in the currently defined | >| >> TLVs". Suggested - "The administrative tag sub-TLVs may | >| >be used with | >| >> with future TLVs as long as their semantics are preserved." | >| >> | >| >> 2. Section 5.2 - The value of the type is wrong - it | >| >should be 2 rather | >| >> than 1. | >| >> | >| >> 3. Section 6 says the ordering of tags is not significant. | >| >However, the | >| >> previous sections (5.1 and 5.2) say that an | >| >implementation may only | >| >> consider the first tag. | >| >> | >| >> 4. Section 7 - List the requirements for receiving the new | >| >Sub-TLVs in | >| >> this compliance section as well (even if they were stated | >| >> previously). | >| >> | >| >> 5. Section 8 - The example talks about R2 associating tag 110 with | >| >> property | >| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >| >1.1.1.0/24 with | >| >> property | >| >> A is adjacent to R1 (which applies to me that R1 originate the | >| >> prefix). | >| >> Please fix either the example or the figure. | >| >> | >| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >| >> | >| >> 1. The abstract contains references. The documents should | >| >be specified | >| >> by name since the abstract can be excerpted. | >| >> | >| >> 2. Line 323 over 72 chars. | >| >> | >| >> Line 323 length is 74 | >| >> Routing in IS-IS", | >| >draft-ietf-isis-wg-multi-topology-03.txt, | >| >> April | >| >> | >| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. | >| >> | >| > | >| > | >| >-- | >| >Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat May 31 06:05:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28270 for ; Sat, 31 May 2003 06:05:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VA2QB01565; Sat, 31 May 2003 06:02:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VA1PB01535 for ; Sat, 31 May 2003 06:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28107; Sat, 31 May 2003 06:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M39H-0006LE-00; Sat, 31 May 2003 05:59:39 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19M39G-0006L3-00; Sat, 31 May 2003 05:59:38 -0400 Received: from SPREVIDI-W2K1.cisco.com ([10.49.250.97]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h4VA0dR11890; Sat, 31 May 2003 12:00:40 +0200 (CEST) Message-Id: <4.3.2.7.2.20030531114157.01a3d2e0@strange-brew.cisco.com> X-Sender: sprevidi@strange-brew.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hannes Gredler From: stefano previdi Subject: Re: [Isis-wg] RE: Comments on Cc: Acee Lindem , "Martin, Christian" , Brad Neal , Routing Area Directorate , isis-wg@ietf.org In-Reply-To: <20030530222903.GA11581@juniper.net> References: <3ED679BC.4060307@redback.com> <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 31 May 2003 12:00:37 +0200 At 12:29 AM 5/31/2003, Hannes Gredler wrote: >acee, > >our implementation currently support two tags > and we pass it on in a ordered way for > internal policy-processing e.g. first tag found is copied > to the variable "tag" and the second tag is > copied to the variable "tag2"; both variables can be > matched against in our internal policy processing > language; > > and thats IMHO the only place > where the draft needs to be more specific: > how an implementation [order, etc.] maps IS-IS-tags > to match-clauses in the local policy processor; > >i am unsure about the ordering and number of supported tags >of other implementations; > stefano, can you shed some light ? I have no specific requirement on this matter... as long as an applicatin is considered compliant when handling the first encountered tag. s. >--- > >SHOULD is IMO a bit too strong wording, i'd be happy >with something like "MAY have more than one tag" > >/hannes > >On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: >| Hannes, >| >| If we agree that having a single 32 bit and/or 64 bit tag is a >| good idea then perhaps we could change the wording of the draft to >| say that an implementation SHOULD only send and interpret a single >| tag and SHOULD ignore data past the first tag. This would allow >| the usage of multiple tags to be gracefully deprecated. >| >| If this isn't acceptable then can we can agree on a small >| finite/known number of tags with suggested usage? >| >| Thanks, >| Acee >| >| Hannes Gredler wrote: >| >pls, keep in mind that there is already code in production that allows >| >more than one tag; >| > >| >common use i have seen so far is >| > >| >tag #1 controls L2L1 leakage >| >tag #2 for informational purposes and points to the area of origin; >| > >| >/hannes >| > >| >On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: >| >| RE: Comments on >| >| >| >| Acee, >| >| >| >| As the original goal was to create a capability similar to OSPF's route >| >tag, >| >| it may be wise to drop this capability. On the otherhand, having >| >multiple >| >| tags per route can provide more information about the route than a single >| >| tag. In this regard, the 32 bit tag operates more like a community, and >| >the >| >| 64 bit tag operates like an extended community. From an implementation >| >| perspective, the same routines for matching and setting these fields >| >should >| >| be similar to the community fields in BGP. >| >| >| >| I would like to solicit the WG for comments on which capability is most >| >| attractive. The goal is not to introduce too much bloat (is it too late >| >for >| >| that?!) while still providing some flexibility. >| >| >| >| As soon as I receive any final comments, I will release the updated >| >draft. >| >| >| >| Thanks for pointing out this critical piece! >| >| >| >| Regards, >| >| chris >| >| >| >| >-----Original Message----- >| >| >From: Acee Lindem [mailto:acee@redback.com] >| >| >Sent: Friday, May 23, 2003 1:50 PM >| >| >To: Acee Lindem >| >| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area >| >| >Directorate >| >| >Subject: Re: Comments on >| >| > >| >| > >| >| >Christian, Stefano, Brad, >| >| > >| >| >The follow-up discussion on the necessity for both 32 bit and >| >| >64 bit tags raises the question as to whether or not it is >| >| >wise to allow an arbitrary number of tags to be advertised. >| >| > >| >| > This draft proposes 2 new "Administrative Tag" sub-TLVs >| >| >to be added >| >| > to TLV 135 and 235. These TLVs specify one or more >| >| >ordered, 32 or 64 >| >| > ~~~~~~~~~~~~~~~ >| >| > bit unsigned integers that may be associated with an IP prefix. >| >| > >| >| >However, the receiver need only use the first. >| >| > >| >| > An implementation may consider only one of the encoded >| >| >tags, in which >| >| > case the first encoded tag must be considered. A tag >| >| >value of zero >| >| > is reserved and should be treated as "no tag". >| >| > >| >| >IMHO, allowing an arbitrary number of tags affords more >| >| >potential for interoperability and deviant applications than >| >| >the 64 bit tag. >| >| > >| >| > >| >| > >| >| > >| >| > >| >| >Acee Lindem wrote: >| >| >> As a member of the routing area directorate, I have reviewed the >| >| >> subject document. Here are my comments: >| >| >> >| >| >> Comments: >| >| >> >| >| >> 1. The last sentence of the abstract doesn't make sense. >| >| >"Additionally, >| >| >> the information can be placed in LSPs that have TLVs as yet >| >| >> undefined, if this information is used to convey the same >| >| >> meaning in these future TLVs as it used in the currently defined >| >| >> TLVs". Suggested - "The administrative tag sub-TLVs may >| >| >be used with >| >| >> with future TLVs as long as their semantics are preserved." >| >| >> >| >| >> 2. Section 5.2 - The value of the type is wrong - it >| >| >should be 2 rather >| >| >> than 1. >| >| >> >| >| >> 3. Section 6 says the ordering of tags is not significant. >| >| >However, the >| >| >> previous sections (5.1 and 5.2) say that an >| >| >implementation may only >| >| >> consider the first tag. >| >| >> >| >| >> 4. Section 7 - List the requirements for receiving the new >| >| >Sub-TLVs in >| >| >> this compliance section as well (even if they were stated >| >| >> previously). >| >| >> >| >| >> 5. Section 8 - The example talks about R2 associating tag 110 with >| >| >> property >| >| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix >| >| >1.1.1.0/24 with >| >| >> property >| >| >> A is adjacent to R1 (which applies to me that R1 originate the >| >| >> prefix). >| >| >> Please fix either the example or the figure. >| >| >> >| >| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >| >| >> >| >| >> 1. The abstract contains references. The documents should >| >| >be specified >| >| >> by name since the abstract can be excerpted. >| >| >> >| >| >> 2. Line 323 over 72 chars. >| >| >> >| >| >> Line 323 length is 74 >| >| >> Routing in IS-IS", >| >| >draft-ietf-isis-wg-multi-topology-03.txt, >| >| >> April >| >| >> >| >| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. >| >| >> >| >| > >| >| > >| >| >-- >| >| >Acee >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat May 31 19:54:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14075 for ; Sat, 31 May 2003 19:54:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VNolB17632; Sat, 31 May 2003 19:50:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TLNRB23407 for ; Thu, 29 May 2003 17:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20539; Thu, 29 May 2003 17:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUqH-0002lJ-00; Thu, 29 May 2003 17:21:45 -0400 Received: from ms-smtp-01.southeast.rr.com ([24.93.67.82]) by ietf-mx with esmtp (Exim 4.12) id 19LUqG-0002lG-00; Thu, 29 May 2003 17:21:44 -0400 Received: from redback.com (rdu162-241-056.nc.rr.com [24.162.241.56]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4TLHhd2006080; Thu, 29 May 2003 17:17:43 -0400 (EDT) Message-ID: <3ED679BC.4060307@redback.com> From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Gredler CC: "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 May 2003 17:21:00 -0400 Content-Transfer-Encoding: 7bit Hannes, If we agree that having a single 32 bit and/or 64 bit tag is a good idea then perhaps we could change the wording of the draft to say that an implementation SHOULD only send and interpret a single tag and SHOULD ignore data past the first tag. This would allow the usage of multiple tags to be gracefully deprecated. If this isn't acceptable then can we can agree on a small finite/known number of tags with suggested usage? Thanks, Acee Hannes Gredler wrote: > pls, keep in mind that there is already code in production that allows > more than one tag; > > common use i have seen so far is > > tag #1 controls L2L1 leakage > tag #2 for informational purposes and points to the area of origin; > > /hannes > > On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: > | RE: Comments on > | > | Acee, > | > | As the original goal was to create a capability similar to OSPF's route tag, > | it may be wise to drop this capability. On the otherhand, having multiple > | tags per route can provide more information about the route than a single > | tag. In this regard, the 32 bit tag operates more like a community, and the > | 64 bit tag operates like an extended community. From an implementation > | perspective, the same routines for matching and setting these fields should > | be similar to the community fields in BGP. > | > | I would like to solicit the WG for comments on which capability is most > | attractive. The goal is not to introduce too much bloat (is it too late for > | that?!) while still providing some flexibility. > | > | As soon as I receive any final comments, I will release the updated draft. > | > | Thanks for pointing out this critical piece! > | > | Regards, > | chris > | > | >-----Original Message----- > | >From: Acee Lindem [mailto:acee@redback.com] > | >Sent: Friday, May 23, 2003 1:50 PM > | >To: Acee Lindem > | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area > | >Directorate > | >Subject: Re: Comments on > | > > | > > | >Christian, Stefano, Brad, > | > > | >The follow-up discussion on the necessity for both 32 bit and > | >64 bit tags raises the question as to whether or not it is > | >wise to allow an arbitrary number of tags to be advertised. > | > > | > This draft proposes 2 new "Administrative Tag" sub-TLVs > | >to be added > | > to TLV 135 and 235. These TLVs specify one or more > | >ordered, 32 or 64 > | > ~~~~~~~~~~~~~~~ > | > bit unsigned integers that may be associated with an IP prefix. > | > > | >However, the receiver need only use the first. > | > > | > An implementation may consider only one of the encoded > | >tags, in which > | > case the first encoded tag must be considered. A tag > | >value of zero > | > is reserved and should be treated as "no tag". > | > > | >IMHO, allowing an arbitrary number of tags affords more > | >potential for interoperability and deviant applications than > | >the 64 bit tag. > | > > | > > | > > | > > | > > | >Acee Lindem wrote: > | >> As a member of the routing area directorate, I have reviewed the > | >> subject document. Here are my comments: > | >> > | >> Comments: > | >> > | >> 1. The last sentence of the abstract doesn't make sense. > | >"Additionally, > | >> the information can be placed in LSPs that have TLVs as yet > | >> undefined, if this information is used to convey the same > | >> meaning in these future TLVs as it used in the currently defined > | >> TLVs". Suggested - "The administrative tag sub-TLVs may > | >be used with > | >> with future TLVs as long as their semantics are preserved." > | >> > | >> 2. Section 5.2 - The value of the type is wrong - it > | >should be 2 rather > | >> than 1. > | >> > | >> 3. Section 6 says the ordering of tags is not significant. > | >However, the > | >> previous sections (5.1 and 5.2) say that an > | >implementation may only > | >> consider the first tag. > | >> > | >> 4. Section 7 - List the requirements for receiving the new > | >Sub-TLVs in > | >> this compliance section as well (even if they were stated > | >> previously). > | >> > | >> 5. Section 8 - The example talks about R2 associating tag 110 with > | >> property > | >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix > | >1.1.1.0/24 with > | >> property > | >> A is adjacent to R1 (which applies to me that R1 originate the > | >> prefix). > | >> Please fix either the example or the figure. > | >> > | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): > | >> > | >> 1. The abstract contains references. The documents should > | >be specified > | >> by name since the abstract can be excerpted. > | >> > | >> 2. Line 323 over 72 chars. > | >> > | >> Line 323 length is 74 > | >> Routing in IS-IS", > | >draft-ietf-isis-wg-multi-topology-03.txt, > | >> April > | >> > | >> 3. Pages 2, 3, 4, and 5 have over 58 lines. > | >> > | > > | > > | >-- > | >Acee > | > > > -- Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg