From acee.lindem@ericsson.com Tue May 4 09:35:06 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B420A3A69A8 for ; Tue, 4 May 2010 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_50=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WllB4z3M8Sy for ; Tue, 4 May 2010 09:35:02 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 44F053A6A1A for ; Tue, 4 May 2010 09:33:23 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o44GcNaG017118 for ; Tue, 4 May 2010 11:38:23 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.130]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 4 May 2010 12:33:03 -0400 From: Acee Lindem CC: "ospf@ietf.org" Date: Tue, 4 May 2010 12:33:02 -0400 Thread-Topic: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 Thread-Index: Acrrp3ehzOt8c1tDRxu/UYQY1NIVcw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:35:06 -0000 Speaking as WG member: I am not opposed to this capability. However, I'm not sure if it justifies = taking two of the remaining router bits. The Router-Information LSA (RFC 49= 70) is really the place for advertising capabilities. It would be ideal if this could be done without an implicit backward compat= ibility mechanism. Doing an election just to see if all routers in the area= are able to recognize the R-bit is complexity that would be nice to avoid= . The draft recommends both setting the R-bit and advertising any transit l= inks with 0xffff cost. Hence, It would be an odd topology where the differe= nces in R-bit capability could cause a routing loop. Unfortunately, it is p= ossible to draw one if you there is a valid path to a destination D, and th= at destination is accessible via multiple routers with varying R-bit capabi= lities :^(.=20 Thanks, Acee=20 On Apr 16, 2010, at 4:44 PM, Acee Lindem wrote: > At the OSPF WG meeting in Anaheim, the subject draft was presented and th= ere seemed to be some interest in such a capability (similar to the overloa= d bit in ISIS). Please indicate whether or not you support making this draf= t a WG document.=20 >=20 > http://www.ietf.org/id/draft-pillay-esnault-ospf-rbit-00.txt >=20 > Thanks, > Acee - (as OSPF WG Co-chair)=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From pauwells@cisco.com Tue May 4 10:15:41 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E19E3A69F5 for ; Tue, 4 May 2010 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEg6bwEYuhVR for ; Tue, 4 May 2010 10:15:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9DBD53A6A36 for ; Tue, 4 May 2010 10:13:06 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,328,1270425600"; d="scan'208";a="524838616" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 04 May 2010 17:12:53 +0000 Received: from pauwells-linux.cisco.com (sjc-pauwells-8713.cisco.com [10.19.20.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o44HCqOO001869; Tue, 4 May 2010 17:12:52 GMT Message-ID: <4BE05594.4090005@cisco.com> Date: Tue, 04 May 2010 12:12:52 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Acee Lindem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 17:15:41 -0000 Hi Acee, Acee Lindem wrote: > Speaking as WG member: > > I am not opposed to this capability. However, I'm not sure if it justifies taking two of the remaining router bits. The Router-Information LSA (RFC 4970) is really the place for advertising capabilities. We understand this concern and are in the process of drafting a new revision that moves the "S" bit to the RI opaque LSA. Note, though, that the definition of the Router Informational Capabilities TLV in RFC 4970 explicitly says "...the informational capabilities advertised have no impact on the OSPF protocol's operation..." so we're defining a new "operational capabilities" TLV to hold this and any future "important" bits. > It would be ideal if this could be done without an implicit backward compatibility mechanism. Doing an election just to see if all routers in the area are able to recognize the R-bit is complexity that would be nice to avoid. The draft recommends both setting the R-bit and advertising any transit links with 0xffff cost. Hence, It would be an odd topology where the differences in R-bit capability could cause a routing loop. Unfortunately, it is possible to draw one if you there is a valid path to a destination D, and that destination is accessible via multiple routers with varying R-bit capabilities :^(. It would be nice, but I don't see any alternative that can be guaranteed to be correct for all topologies. Thanks, Paul > > Thanks, > Acee > > > On Apr 16, 2010, at 4:44 PM, Acee Lindem wrote: > >> At the OSPF WG meeting in Anaheim, the subject draft was presented and there seemed to be some interest in such a capability (similar to the overload bit in ISIS). Please indicate whether or not you support making this draft a WG document. >> >> http://www.ietf.org/id/draft-pillay-esnault-ospf-rbit-00.txt >> >> Thanks, >> Acee - (as OSPF WG Co-chair) >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Tue May 4 15:24:16 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1523A6AAD for ; Tue, 4 May 2010 15:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FphFFcbScra8 for ; Tue, 4 May 2010 15:24:12 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1227428C213 for ; Tue, 4 May 2010 14:31:26 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o44La2bT023221; Tue, 4 May 2010 16:36:02 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.130]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 4 May 2010 17:30:46 -0400 From: Acee Lindem To: Paul Wells Date: Tue, 4 May 2010 17:30:44 -0400 Thread-Topic: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 Thread-Index: Acrr0Q4lyzScWKfRRYeUuzJKAa7KVg== Message-ID: <3BBC4C74-0081-4A04-B0C1-6DD084A6ADCC@ericsson.com> References: <4BE05594.4090005@cisco.com> In-Reply-To: <4BE05594.4090005@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 22:24:17 -0000 Hi Paul, On May 4, 2010, at 1:12 PM, Paul Wells wrote: > Hi Acee, >=20 > Acee Lindem wrote: >> Speaking as WG member: >>=20 >> I am not opposed to this capability. However, I'm not sure if it justifi= es taking two of the remaining router bits. The Router-Information LSA (RFC= 4970) is really the place for advertising capabilities. >=20 > We understand this concern and are in the process of drafting a=20 > new revision that moves the "S" bit to the RI opaque LSA. Note,=20 > though, that the definition of the Router Informational=20 > Capabilities TLV in RFC 4970 explicitly says "...the informational=20 > capabilities advertised have no impact on the OSPF protocol's=20 > operation..." so we're defining a new "operational capabilities"=20 > TLV to hold this and any future "important" bits. I remember we made the RFC 4970 statement due to debate during IESG review = regarding backward compatibility for existing capabilities. Adding a new TL= V for new capabilities that do impact protocol operation sounds like a grea= t idea.=20 >=20 >> It would be ideal if this could be done without an implicit backward com= patibility mechanism. Doing an election just to see if all routers in the a= rea are able to recognize the R-bit is complexity that would be nice to av= oid. The draft recommends both setting the R-bit and advertising any transi= t links with 0xffff cost. Hence, It would be an odd topology where the diff= erences in R-bit capability could cause a routing loop. Unfortunately, it i= s possible to draw one if you there is a valid path to a destination D, and= that destination is accessible via multiple routers with varying R-bit cap= abilities :^(.=20 >=20 > It would be nice, but I don't see any alternative that can be=20 > guaranteed to be correct for all topologies. We discussed this over a beer and the only thing we could come up with was = putting the configuration and responsibility in the hands of the system adm= inistrator (since IGPs are under the control of a single administrative dom= ain). However, this would be a departure from what we've done heretofore in= the OSPF WG.=20 Thanks, Acee=20 >=20 > Thanks, > Paul >=20 >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >> On Apr 16, 2010, at 4:44 PM, Acee Lindem wrote: >>=20 >>> At the OSPF WG meeting in Anaheim, the subject draft was presented and = there seemed to be some interest in such a capability (similar to the overl= oad bit in ISIS). Please indicate whether or not you support making this dr= aft a WG document.=20 >>>=20 >>> http://www.ietf.org/id/draft-pillay-esnault-ospf-rbit-00.txt >>>=20 >>> Thanks, >>> Acee - (as OSPF WG Co-chair)=20 >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Tue May 4 15:40:23 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1BB28C21A for ; Tue, 4 May 2010 15:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.967 X-Spam-Level: X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy+AjRC+3Jqd for ; Tue, 4 May 2010 15:40:22 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0A28328C1E0 for ; Tue, 4 May 2010 14:53:08 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o44Lw9OB001354 for ; Tue, 4 May 2010 16:58:09 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.130]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 4 May 2010 17:52:53 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Tue, 4 May 2010 17:52:51 -0400 Thread-Topic: RFC 3623 Ambiguity Thread-Index: Acrr1CWfHvVwlKPTQrqxJhWLICGi5Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] RFC 3623 Ambiguity X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 22:40:23 -0000 It has come to my attention that the behavior for helper routers during a g= raceful restart in RFC 3623 suffers from multiple interpretations. Here is the excerpt from section 3.2, page 8: When Router Y exits helper mode for X on a given network segment, it reoriginates its LSAs based on the current state of its adjacency to Router X over the segment. In detail, Y takes the following actions: a) Y recalculates the Designated Router for the segment, b) Y reoriginates its router-LSA for the segment's OSPF area, c) if Y is Designated Router for the segment, it reoriginates the network-LSA for the segment and d) if the segment was a virtual link, Y reoriginates its router- LSA for the virtual link's transit area. I know what what was meant by this text since I was one of the authors. For= robustness, the restarting router will reoriginate its Router-LSAs and Net= work-LSAs as described in section 2.3. However the phrase "based on the cur= rent state of its adjacency to Router X over the segment" was meant to mean= that the helper routers would reoriginate their LSAs when graceful restart= constituted a change to the LSA. However, it appears some have interprete= d this to mean that the helper should unconditionally reoriginate its LSAs.= I know one popular test equipment vendor interpreted it in this manner. I'= d be curious as to whether others interpreted it this way as well. Thanks, Acee