From yiya@cisco.com Tue May 1 08:20:01 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D043A21F8AB5 for ; Tue, 1 May 2012 08:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+HKGUOWEv06 for ; Tue, 1 May 2012 08:20:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 16CF521F8AB4 for ; Tue, 1 May 2012 08:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=1936; q=dns/txt; s=iport; t=1335885601; x=1337095201; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=ZZ4JpF2RIGP3zCqQfL3oUAz7Px3VgAg32jzzAmjn868=; b=bY1QMDXJ7VX+w92XgPn23Ci1dG3sXGNmEi68Q4moQhGhD7UG68m15s0I wC2Wvy+bcT3ru/rk2wWOP4HirIwTsL1IFsDoesydefyIgf3GK37FYtizK k8h+TnGSlKxyEMSo/OCKoVfuWyJMxOm8BkS5CVZDjYndki0QX/nu11uVv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIFAAz+n0+tJXHB/2dsb2JhbABEr2uDAYEHggkBAQEDAQEBAQ8BCh00EAsLGCMLJzAGARIJGYdmBQuaJZ9akCZjBJV+gRGNSIFpgwQ X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="79390048" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 01 May 2012 15:20:00 +0000 Received: from dhcp-64-102-95-241.cisco.com (dhcp-64-102-95-241.cisco.com [64.102.95.241]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q41FK0WD000400; Tue, 1 May 2012 15:20:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Yi Yang In-Reply-To: Date: Tue, 1 May 2012 11:20:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37C14992-8864-4DA7-911C-64DDC8A4404F@cisco.com> References: <84AB6152-7E34-4E21-9D2E-32DB3ACD93DE@ericsson.com> <529797C2-F390-4224-A1DC-EBDC5142BC9F@ericsson.com> To: Acee Lindem , OSPF List X-Mailer: Apple Mail (2.1084) Subject: Re: [OSPF] OSPF WG Last Call for "Hiding Transit-only Networks in OSPF " - X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 15:20:02 -0000 The updated draft was just published at = http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-03.txt.=20 The changes include some modification on OSPFv3 specification, = forwarding address processing and virtual link handling. Thanks for all the feedback! Yi On Mar 23, 2012, at 6:34 PM, Acee Lindem wrote: > The OSPF WG last call has ended. There was a comment related to OSPFv3 = which Alvaro will update the draft to reflect.=20 > Thanks, > Acee=20 > On Feb 8, 2012, at 12:07 PM, Acee Lindem wrote: >=20 >> As I have heard no objections, I'm beginning the 2 week OSPF Working = Group last call for draft-ietf-ospf-prefix-hiding-02.txt. >> Please review the draft and post your last call comments prior to = 12:00 AM PDT on February 23nd, 2012.=20 >> Here is a URL for your convenience:=20 >>=20 >> http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-02.txt >>=20 >> Thanks, >> Acee=20 >>=20 >> On Jan 26, 2012, at 11:19 AM, Acee Lindem wrote: >>=20 >>> As WG co-chair, I have reviewed this document and believe it is = ready for OSPF WG last call. Any other opinions?=20 >>> There is at least one implementation. Here is a URL for you = convenience: >>>=20 >>> http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-01.txt >>>=20 >>> There is an IPR disclosure on this draft: >>>=20 >>> http://datatracker.ietf.org/ipr/1423/ >>>=20 >>> I will start WG last call next week if I don't hear any objections. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=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 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Tue May 1 16:49:51 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876C421E8094 for ; Tue, 1 May 2012 16:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQAojvfnspbB for ; Tue, 1 May 2012 16:49:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C00D421E8086 for ; Tue, 1 May 2012 16:49:50 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q41NnmVK008179; Tue, 1 May 2012 18:49:49 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.124]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 1 May 2012 19:49:44 -0400 From: Acee Lindem To: Yi Yang Date: Tue, 1 May 2012 19:49:43 -0400 Thread-Topic: [OSPF] OSPF WG Last Call for "Hiding Transit-only Networks in OSPF " - Thread-Index: Ac0n9RWrAvKzxIh5TA2IcbRBOLQYYw== Message-ID: References: <84AB6152-7E34-4E21-9D2E-32DB3ACD93DE@ericsson.com> <529797C2-F390-4224-A1DC-EBDC5142BC9F@ericsson.com> <37C14992-8864-4DA7-911C-64DDC8A4404F@cisco.com> In-Reply-To: <37C14992-8864-4DA7-911C-64DDC8A4404F@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 List Subject: Re: [OSPF] OSPF WG Last Call for "Hiding Transit-only Networks in OSPF " - X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 23:49:51 -0000 Can everyone who submitted comments during the OSPF WG last call please ass= ure your comments are satisfied in this version? We want to move forward an= d submit this version to the AD for progression.=20 Thanks, Acee=20 On May 1, 2012, at 11:20 AM, Yi Yang wrote: > The updated draft was just published at http://www.ietf.org/id/draft-ietf= -ospf-prefix-hiding-03.txt.=20 >=20 > The changes include some modification on OSPFv3 specification, forwarding= address processing and virtual link handling. >=20 > Thanks for all the feedback! >=20 > Yi >=20 >=20 >=20 > On Mar 23, 2012, at 6:34 PM, Acee Lindem wrote: >=20 >> The OSPF WG last call has ended. There was a comment related to OSPFv3 w= hich Alvaro will update the draft to reflect.=20 >> Thanks, >> Acee=20 >> On Feb 8, 2012, at 12:07 PM, Acee Lindem wrote: >>=20 >>> As I have heard no objections, I'm beginning the 2 week OSPF Working Gr= oup last call for draft-ietf-ospf-prefix-hiding-02.txt. >>> Please review the draft and post your last call comments prior to 12:00= AM PDT on February 23nd, 2012.=20 >>> Here is a URL for your convenience:=20 >>>=20 >>> http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-02.txt >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>> On Jan 26, 2012, at 11:19 AM, Acee Lindem wrote: >>>=20 >>>> As WG co-chair, I have reviewed this document and believe it is ready = for OSPF WG last call. Any other opinions?=20 >>>> There is at least one implementation. Here is a URL for you convenienc= e: >>>>=20 >>>> http://www.ietf.org/id/draft-ietf-ospf-prefix-hiding-01.txt >>>>=20 >>>> There is an IPR disclosure on this draft: >>>>=20 >>>> http://datatracker.ietf.org/ipr/1423/ >>>>=20 >>>> I will start WG last call next week if I don't hear any objections. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=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 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 From acee.lindem@ericsson.com Mon May 7 06:10:47 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4563B21F862A for ; Mon, 7 May 2012 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LCoWC185QNH for ; Mon, 7 May 2012 06:10:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23F0A21F8629 for ; Mon, 7 May 2012 06:10:46 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q47DAhVC011051; Mon, 7 May 2012 08:10:44 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.124]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 7 May 2012 09:10:41 -0400 From: Acee Lindem To: Stewart Bryant Date: Mon, 7 May 2012 09:10:38 -0400 Thread-Topic: OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt Thread-Index: Ac0sUs1KlVFa2FZcT+K06k1D2zTcoQ== Message-ID: <47A0E1C7-12D4-465E-9A15-E5FBCC2F3EDE@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_47A0E1C712D4465E9A15E5FBCC2F3EDEericssoncom_" MIME-Version: 1.0 Cc: "Jeffrey \(Zhaohui\) Zhang" , OSPF List Subject: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 07 May 2012 13:10:47 -0000 --_002_47A0E1C712D4465E9A15E5FBCC2F3EDEericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, The OSPF WG requests that the subject document be submitted to the IESG for= publication. The document write-up is attached.=20 Thanks, Acee=20 --_002_47A0E1C712D4465E9A15E5FBCC2F3EDEericssoncom_ Content-Type: text/plain; name="ospf-wg-hybrid-interface-writeup.txt" Content-Description: ospf-wg-hybrid-interface-writeup.txt Content-Disposition: attachment; filename="ospf-wg-hybrid-interface-writeup.txt"; size=6763; creation-date="Mon, 07 May 2012 13:10:40 GMT"; modification-date="Mon, 07 May 2012 13:10:40 GMT" Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA0KSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWwsIEV4cGVyaW1lbnRhbCwg b3IgSGlzdG9yaWMpPyAgV2h5DQppcyB0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/ICBJcyB0 aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZCBpbiB0aGUNCnRpdGxlIHBhZ2UgaGVhZGVyPw0KDQog ICAgIFByb3Bvc2VkIFN0YW5kYXJkIA0KDQooMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2Vt ZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DQpXcml0ZS1VcC4gUGxlYXNlIHBy b3ZpZGUgc3VjaCBhIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4gUmVjZW50DQpleGFt cGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJv dmVkDQpkb2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZv bGxvd2luZyBzZWN0aW9uczoNCg0KICAgICBUZWNobmljYWwgU3VtbWFyeSANCg0KICAgICBUaGlz IGRyYWZ0IGV4dGVuZHMgT1NQRnYyIHdpdGggYW4gYWRkaXRpb25hbCBpbnRlcmZhY2UgdHlwZSB0 aGF0DQogICAgIGhhcyB0aGUgcHJvcGVydHkgb2Ygc3VwcG9ydGluZyB0aGUgYWRqYWNlbmN5IHJl ZHVjdGlvbiBhbmQgZmxvb2RpbmcgDQogICAgIG9wdGltaXphdGlvbnMgb2YgYnJvYWRjYXN0IG5l dHdvcmtzIHdoaWxlIHN0aWxsIGFsbG93aW5nIHNlcGFyYXRlIA0KICAgICBjb3N0cyB0byBiZSBz cGVjaWZpZWQgZm9yIGVhY2ggbmVpZ2hib3IuIA0KDQogICAgIFdvcmtpbmcgR3JvdXAgU3VtbWFy eSANCg0KICAgICBUaGUgb25seSBkaXNjdXNzaW9uIHdvcnRoIG5vdGluZyB3YXMgd2FzIGhvdyB0 aGlzIGRvY3VtZW50IHdhcyANCiAgICAgcG9zaXRpb25lZCBhZ2FpbnN0IHRoZSBwcmV2aW91c2x5 IHB1Ymxpc2hlZCBNQU5FVCBkb2N1bWVudHMuIFdlIA0KICAgICBhZ3JlZWQgdGhhdCB0aGUgTUFO RVQgbWVjaGFuaXNtcyBjb3VsZCBiZSB1c2VkIHRvIGFjY29tcGxpc2ggdGhlDQogICAgIHNhbWUg Z29hbCBidXQgdGhhdCB0aGUgc2ltcGxpY2l0eSBvZiB0aGlzIGRyYWZ0IHdhcnJlbnRzIA0KICAg ICBzdGFuZGFyZGl6YXRpb24gYnkgdGhlIHdvcmtpbmcgZ3JvdXAuIA0KDQogICAgIERvY3VtZW50 IFF1YWxpdHkgDQoNCiAgICAgVGhlIGRvY3VtZW50IGhhcyBnb25lIHRocm91Z2ggc2V2ZXJhbCBX RyByZXZpZXcgY3ljbGVzIGFuZCANCiAgICAgcmV2aXNpb25zLiBUaGVyZSBpcyBhdCBsZWFzdCBv bmUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGluaXRpYWwNCiAgICAgcmV2aXNpb24uIA0KDQogICAg IFBlcnNvbm5lbA0KICAgICAgDQogICAgIEFjZWUgTGluZGVtIGlzIHRoZSBkb2N1bWVudCBzaGVw aGVyZCBhbmQgU3Rld2FydCBCcnlhbnQgaXMgdGhlIA0KICAgICByZXNwb25zaWJsZSBBRC4gDQoN Cg0KKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlzIGRvY3VtZW50IHRoYXQg d2FzIHBlcmZvcm1lZCBieQ0KdGhlIERvY3VtZW50IFNoZXBoZXJkLiAgSWYgdGhpcyB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkNCmZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4 cGxhaW4gd2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG8NCnRoZSBJRVNHLg0K DQogICAgVGhlIGRvY3VtZW50IHdhcyBwcmVzZW50ZWQgYXQgdHdvIElFVEZzIGFuZCB3ZW50IHRo cm91Z2ggc2V2ZXJhbCBXRw0KICAgIHJldmlld3MuIA0KDQooNCkgRG9lcyB0aGUgZG9jdW1lbnQg U2hlcGhlcmQgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yDQpicmVhZHRoIG9m IHRoZSByZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQoNCiAgICBOby4gDQoNCig1 KSBEbyBwb3J0aW9ucyBvZiB0aGUgZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3Vs YXIgb3IgZnJvbQ0KYnJvYWRlciBwZXJzcGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlv bmFsIGNvbXBsZXhpdHksIEFBQSwgRE5TLA0KREhDUCwgWE1MLCBvciBpbnRlcm5hdGlvbmFsaXph dGlvbj8gSWYgc28sIGRlc2NyaWJlIHRoZSByZXZpZXcgdGhhdA0KdG9vayBwbGFjZS4NCg0KICAg IE5vLg0KDQooNikgRGVzY3JpYmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0 IHRoZSBEb2N1bWVudCBTaGVwaGVyZA0KaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0aGUNCklFU0cgc2hvdWxkIGJlIGF3YXJl IG9mPyBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ0Kd2l0 aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IgaGFzIGNvbmNlcm5zIHdoZXRoZXIg dGhlcmUgcmVhbGx5DQppcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRoZSBpbnRl cmVzdGVkIGNvbW11bml0eSBoYXMNCmRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRp Y2F0ZWQgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZQ0KdGhlIGRvY3VtZW50LCBkZXRh aWwgdGhvc2UgY29uY2VybnMgaGVyZS4NCg0KICAgTm9uZS4gDQoNCig3KSBIYXMgZWFjaCBhdXRo b3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSDQpkaXNjbG9zdXJl cyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJD UCA3OA0KYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gSWYgbm90LCBleHBsYWlu IHdoeS4NCg0KICAgWWVzLiAgIA0KDQooOCkgSGFzIGFuIElQUiBkaXNjbG9zdXJlIGJlZW4gZmls ZWQgdGhhdCByZWZlcmVuY2VzIHRoaXMgZG9jdW1lbnQ/DQpJZiBzbywgc3VtbWFyaXplIGFueSBk aXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGluZyB0aGUgSVBSDQpkaXNjbG9zdXJlcy4N CiAgICANCiAgIFllcyAtIERlZmVuc2l2ZSBwYXRlbnQuIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvaXByLzE1MjkvIA0KDQooOSkgSG93IHNvbGlkIGlzIHRoZSBjb25zZW5zdXMgb2YgdGhl IGludGVyZXN0ZWQgY29tbXVuaXR5IGJlaGluZCB0aGlzDQpkb2N1bWVudD8gRG9lcyBpdCByZXBy ZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywNCndpdGgg b3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgYXMg YSB3aG9sZQ0KdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gDQoNCiAgIFRoZXNlIGlzIGNv bnNlbnN1cyBiZWhpbmQgdGhlIGRyYWZ0IHdpdGggdGhlIG9ubHkgcXVlc3Rpb25zDQogICBjb21p bmcgYXV0aG9ycyBvZiBPU1BGIE1BTkVUIGV4cGVyaW1lbnRhbCBSRkNzIHRoYXQgbWF5IGJlDQog ICB1c2VkIHRvIGFjY29tcGxpc2ggdGhlIHNhbWUgZW5kIG9mIGdldHRpbmcgdGhlIHVuZXF1YWwg Y29zdHMNCiAgIGFuZCBleHBsb2l0IG11bHRpY2FzdCBmbG9vZGluZy4gV2UgcmVzb2x2ZWQgdGhl c2UgcXVlc3Rpb25zDQogICBieSBhZ3JlZWluZyB0byBhbHNvIGFjY2VwdCBkcmFmdCBkZXNjcmli aW5nIGhvdyB0aGVzZSBPU1BGDQogICBNQU5FVCBleHRlbnNpb25zIGNvdWxkIGJlIHVzZWQuIA0K DQooMTApIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGlj YXRlZCBleHRyZW1lIA0KZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFy ZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlDQplbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9u c2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhDQpzZXBhcmF0ZSBlbWFpbCBi ZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyBwdWJsaWNseSBhdmFpbGFibGUuKSANCiANCiAg IE5vLiANCg0KKDExKSBJZGVudGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQg aGFzIGZvdW5kIGluIHRoaXMNCmRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9v bHMvaWRuaXRzLyBhbmQgdGhlIEludGVybmV0LURyYWZ0cw0KQ2hlY2tsaXN0KS4gQm9pbGVycGxh dGUgY2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlDQp0aG9yb3Vn aC4NCg0KICAgQWxsIGlkbml0cyBlcnJvcnMgYW5kIHdhcm5pbmdzIGhhdmUgYmVlbiByZXNvbHZl ZC4NCg0KKDEyKSBEZXNjcmliZSBob3cgdGhlIGRvY3VtZW50IG1lZXRzIGFueSByZXF1aXJlZCBm b3JtYWwgcmV2aWV3DQpjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3RvciwgbWVkaWEgdHlw ZSwgYW5kIFVSSSB0eXBlIHJldmlld3MuDQoNCiAgIE5vdCBhcHBsaWNhYmxlLiANCg0KKDEzKSBI YXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBh cw0KZWl0aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NCg0KICAgWWVzLg0KDQooMTQpIEFy ZSB0aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCBhcmUgbm90IHJl YWR5IGZvcg0KYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRl PyBJZiBzdWNoIG5vcm1hdGl2ZQ0KcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgcGxhbiBm b3IgdGhlaXIgY29tcGxldGlvbj8NCg0KICAgIE5vLiANCg0KKDE1KSBBcmUgdGhlcmUgZG93bndh cmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8NCklmIHNv LCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydCB0aGUgQXJlYSBEaXJl Y3RvciBpbg0KdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUuDQoNCiAgICBOby4gIA0KDQooMTYpIFdp bGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkg ZXhpc3RpbmcNClJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBo ZWFkZXIsIGxpc3RlZCBpbiB0aGUNCmFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRy b2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3QgbGlzdGVkDQppbiB0aGUgQWJzdHJhY3QgYW5k IEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUgcGFydCBvZg0KdGhl IGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUg b3RoZXIgUkZDcw0KaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0 aGUgZG9jdW1lbnQsIGV4cGxhaW4gd2h5DQp0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgY29uc2lk ZXJzIGl0IHVubmVjZXNzYXJ5Lg0KDQogICAgWWVzLiBVcGRhdGVzIFJGQyAyMzI4IGFuZCBSRkMg NTM0MC4gDQoNCigxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50IFNoZXBoZXJkJ3MgcmV2aWV3IG9m IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zDQpzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJk IHRvIGl0cyBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mIHRoZQ0KZG9jdW1lbnQuIENvbmZp cm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVudCBtYWtlcw0K YXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25zIGluIElBTkEg cmVnaXN0cmllcy4NCkNvbmZpcm0gdGhhdCBhbnkgcmVmZXJlbmNlZCBJQU5BIHJlZ2lzdHJpZXMg aGF2ZSBiZWVuIGNsZWFybHkNCmlkZW50aWZpZWQuIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVk IElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGENCmRldGFpbGVkIHNwZWNpZmljYXRpb24gb2YgdGhl IGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3RyeSwgdGhhdA0KYWxsb2NhdGlvbnMgcHJv Y2VkdXJlcyBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmluZWQsIGFuZCBhDQpyZWFz b25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnkgaGFzIGJlZW4gc3VnZ2VzdGVkIChzZWUg UkZDIDUyMjYpLg0KDQogICAgVGhpcyBkb2N1bWVudCBkb2Vzbid0IHJlcXVpcmUgYW55IElBTkEg YWN0aW9ucy4gVGhlIG9uZSBhZGRlZCBjb2RlDQogICAgcG9pbnQgZm9yIHRoZSBuZXcgaW50ZXJm YWNlIHR5cGUgaXMgbm90IHBhcnQgb2YgdGhlIHByb3RvY29sIC0gb25seQ0KICAgIHRoZSByZWZl cmVuY2UgaW1wbGVtZW50YXRpb24gdXNlZCB0byBkZXNjcmliZXIgcHJvdG9jb2wgYmVoYXZpb3Iu ICANCg0KKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBFeHBl cnQgUmV2aWV3IGZvciBmdXR1cmUNCmFsbG9jYXRpb25zLiBQcm92aWRlIGFueSBwdWJsaWMgZ3Vp ZGFuY2UgdGhhdCB0aGUgSUVTRyB3b3VsZCBmaW5kDQp1c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJ QU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVzLg0KDQogICAgIE5vbmUuICANCg0K KDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0 byB2YWxpZGF0ZQ0Kc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWwg bGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsDQpCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywg ZXRjLg0KDQogICAgIE5vdCBBcHBsaWNhYmxlLiANCg0KICANCg== --_002_47A0E1C712D4465E9A15E5FBCC2F3EDEericssoncom_-- From acee.lindem@ericsson.com Mon May 7 09:37:30 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C27421F8664 for ; Mon, 7 May 2012 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6xB2rCswYyQ for ; Mon, 7 May 2012 09:37:29 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 48B1921F85F2 for ; Mon, 7 May 2012 09:37:26 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q47GbOSa000814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 May 2012 11:37:25 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.124]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 7 May 2012 12:37:24 -0400 From: Acee Lindem To: Stewart Bryant Date: Mon, 7 May 2012 12:37:22 -0400 Thread-Topic: Publication request for OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt Thread-Index: Ac0sb65HjkSAtmq9RsK47570hEkgMA== Message-ID: <3D4F9603-65A7-45C7-A679-A43E2AA0A19C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_3D4F960365A745C7A679A43E2AA0A19Cericssoncom_" MIME-Version: 1.0 Cc: "Jeffrey \(Zhaohui\) Zhang" , OSPF List Subject: [OSPF] Publication request for OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 07 May 2012 16:37:30 -0000 --_002_3D4F960365A745C7A679A43E2AA0A19Cericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, Please publish draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt as a Standards = Track RFC.=20 Thanks, Acee=20 --_002_3D4F960365A745C7A679A43E2AA0A19Cericssoncom_ Content-Type: text/plain; name="ospf-wg-hybrid-interface-writeup.txt" Content-Description: ospf-wg-hybrid-interface-writeup.txt Content-Disposition: attachment; filename="ospf-wg-hybrid-interface-writeup.txt"; size=6929; creation-date="Mon, 07 May 2012 16:37:24 GMT"; modification-date="Mon, 07 May 2012 16:37:24 GMT" Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA0NCkludGVybmV0IFN0YW5kYXJkLCBJbmZvcm1hdGlvbmFsLCBFeHBlcmltZW50YWws IG9yIEhpc3RvcmljKT8gIFdoeQ0NCmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9mIFJGQz8gIElz IHRoaXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZQ0NCnRpdGxlIHBhZ2UgaGVhZGVyPw0N Cg0NCiAgICAgUHJvcG9zZWQgU3RhbmRhcmQgDQ0KDQ0KKDIpIFRoZSBJRVNHIGFwcHJvdmFsIGFu bm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50IEFubm91bmNlbWVudA0NCldyaXRlLVVwLiBQ bGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNl bnQNDQpleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMg Zm9yIGFwcHJvdmVkDQ0KZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgYW5ub3VuY2VtZW50IGNvbnRh aW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6DQ0KDQ0KICAgICBUZWNobmljYWwgU3VtbWFyeSAN DQoNDQogICAgIFRoaXMgZHJhZnQgZXh0ZW5kcyBPU1BGdjIgd2l0aCBhbiBhZGRpdGlvbmFsIGlu dGVyZmFjZSB0eXBlIHRoYXQNDQogICAgIGhhcyB0aGUgcHJvcGVydHkgb2Ygc3VwcG9ydGluZyB0 aGUgYWRqYWNlbmN5IHJlZHVjdGlvbiBhbmQgZmxvb2RpbmcgDQ0KICAgICBvcHRpbWl6YXRpb25z IG9mIGJyb2FkY2FzdCBuZXR3b3JrcyB3aGlsZSBzdGlsbCBhbGxvd2luZyBzZXBhcmF0ZSANDQog ICAgIGNvc3RzIHRvIGJlIHNwZWNpZmllZCBmb3IgZWFjaCBuZWlnaGJvci4gDQ0KDQ0KICAgICBX b3JraW5nIEdyb3VwIFN1bW1hcnkgDQ0KDQ0KICAgICBUaGUgb25seSBkaXNjdXNzaW9uIHdvcnRo IG5vdGluZyB3YXMgd2FzIGhvdyB0aGlzIGRvY3VtZW50IHdhcyANDQogICAgIHBvc2l0aW9uZWQg YWdhaW5zdCB0aGUgcHJldmlvdXNseSBwdWJsaXNoZWQgTUFORVQgZG9jdW1lbnRzLiBXZSANDQog ICAgIGFncmVlZCB0aGF0IHRoZSBNQU5FVCBtZWNoYW5pc21zIGNvdWxkIGJlIHVzZWQgdG8gYWNj b21wbGlzaCB0aGUNDQogICAgIHNhbWUgZ29hbCBidXQgdGhhdCB0aGUgc2ltcGxpY2l0eSBvZiB0 aGlzIGRyYWZ0IHdhcnJlbnRzIA0NCiAgICAgc3RhbmRhcmRpemF0aW9uIGJ5IHRoZSB3b3JraW5n IGdyb3VwLiANDQoNDQogICAgIERvY3VtZW50IFF1YWxpdHkgDQ0KDQ0KICAgICBUaGUgZG9jdW1l bnQgaGFzIGdvbmUgdGhyb3VnaCBzZXZlcmFsIFdHIHJldmlldyBjeWNsZXMgYW5kIA0NCiAgICAg cmV2aXNpb25zLiBUaGVyZSBpcyBhdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGlu aXRpYWwNDQogICAgIHJldmlzaW9uLiANDQoNDQogICAgIFBlcnNvbm5lbA0NCiAgICAgIA0NCiAg ICAgQWNlZSBMaW5kZW0gaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCBTdGV3YXJ0IEJyeWFu dCBpcyB0aGUgDQ0KICAgICByZXNwb25zaWJsZSBBRC4gDQ0KDQ0KDQ0KKDMpIEJyaWVmbHkgZGVz Y3JpYmUgdGhlIHJldmlldyBvZiB0aGlzIGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ0N CnRoZSBEb2N1bWVudCBTaGVwaGVyZC4gIElmIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQg aXMgbm90IHJlYWR5DQ0KZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFpbiB3aHkgdGhlIGRv Y3VtZW50IGlzIGJlaW5nIGZvcndhcmRlZCB0bw0NCnRoZSBJRVNHLg0NCg0NCiAgICBUaGUgZG9j dW1lbnQgd2FzIHByZXNlbnRlZCBhdCB0d28gSUVURnMgYW5kIHdlbnQgdGhyb3VnaCBzZXZlcmFs IFdHDQ0KICAgIHJldmlld3MuIA0NCg0NCig0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBo YXZlIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3INDQpicmVhZHRoIG9mIHRoZSByZXZp ZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQ0KDQ0KICAgIE5vLiANDQoNDQooNSkgRG8g cG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9y IGZyb20NDQpicm9hZGVyIHBlcnNwZWN0aXZlLCBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwg Y29tcGxleGl0eSwgQUFBLCBETlMsDQ0KREhDUCwgWE1MLCBvciBpbnRlcm5hdGlvbmFsaXphdGlv bj8gSWYgc28sIGRlc2NyaWJlIHRoZSByZXZpZXcgdGhhdA0NCnRvb2sgcGxhY2UuDQ0KDQ0KICAg IE5vLg0NCg0NCig2KSBEZXNjcmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRo YXQgdGhlIERvY3VtZW50IFNoZXBoZXJkDQ0KaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRo ZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0aGUNDQpJRVNHIHNob3VsZCBiZSBh d2FyZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUN DQp3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hl dGhlciB0aGVyZSByZWFsbHkNDQppcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRo ZSBpbnRlcmVzdGVkIGNvbW11bml0eSBoYXMNDQpkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBo YXMgaW5kaWNhdGVkIHRoYXQgaXQgc3RpbGwgd2lzaGVzIHRvIGFkdmFuY2UNDQp0aGUgZG9jdW1l bnQsIGRldGFpbCB0aG9zZSBjb25jZXJucyBoZXJlLg0NCg0NCiAgIE5vbmUuIA0NCg0NCig3KSBI YXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBS DQ0KZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJv dmlzaW9ucyBvZiBCQ1AgNzgNDQphbmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBiZWVuIGZpbGVkLiBJ ZiBub3QsIGV4cGxhaW4gd2h5Lg0NCg0NCiAgIFllcy4gICANDQoNDQooOCkgSGFzIGFuIElQUiBk aXNjbG9zdXJlIGJlZW4gZmlsZWQgdGhhdCByZWZlcmVuY2VzIHRoaXMgZG9jdW1lbnQ/DQ0KSWYg c28sIHN1bW1hcml6ZSBhbnkgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhl IElQUg0NCmRpc2Nsb3N1cmVzLg0NCiAgICANDQogICBZZXMgLSBEZWZlbnNpdmUgcGF0ZW50LiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNTI5LyANDQoNDQooOSkgSG93IHNvbGlk IGlzIHRoZSBjb25zZW5zdXMgb2YgdGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGJlaGluZCB0aGlz DQ0KZG9jdW1lbnQ/IERvZXMgaXQgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2Yg YSBmZXcgaW5kaXZpZHVhbHMsDQ0Kd2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRo ZSBpbnRlcmVzdGVkIGNvbW11bml0eSBhcyBhIHdob2xlDQ0KdW5kZXJzdGFuZCBhbmQgYWdyZWUg d2l0aCBpdD8gDQ0KDQ0KICAgVGhlc2UgaXMgY29uc2Vuc3VzIGJlaGluZCB0aGUgZHJhZnQgd2l0 aCB0aGUgb25seSBxdWVzdGlvbnMNDQogICBjb21pbmcgYXV0aG9ycyBvZiBPU1BGIE1BTkVUIGV4 cGVyaW1lbnRhbCBSRkNzIHRoYXQgbWF5IGJlDQ0KICAgdXNlZCB0byBhY2NvbXBsaXNoIHRoZSBz YW1lIGVuZCBvZiBnZXR0aW5nIHRoZSB1bmVxdWFsIGNvc3RzDQ0KICAgYW5kIGV4cGxvaXQgbXVs dGljYXN0IGZsb29kaW5nLiBXZSByZXNvbHZlZCB0aGVzZSBxdWVzdGlvbnMNDQogICBieSBhZ3Jl ZWluZyB0byBhbHNvIGFjY2VwdCBkcmFmdCBkZXNjcmliaW5nIGhvdyB0aGVzZSBPU1BGDQ0KICAg TUFORVQgZXh0ZW5zaW9ucyBjb3VsZCBiZSB1c2VkLiANDQoNDQooMTApIEhhcyBhbnlvbmUgdGhy ZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lIA0NCmRpc2Nv bnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbiBz ZXBhcmF0ZQ0NCmVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9y LiAoSXQgc2hvdWxkIGJlIGluIGENDQpzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rp b25uYWlyZSBpcyBwdWJsaWNseSBhdmFpbGFibGUuKSANDQogDQ0KICAgTm8uIA0NCg0NCigxMSkg SWRlbnRpZnkgYW55IElEIG5pdHMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBmb3VuZCBpbiB0 aGlzDQ0KZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMvIGFu ZCB0aGUgSW50ZXJuZXQtRHJhZnRzDQ0KQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUgY2hlY2tzIGFy ZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlDQ0KdGhvcm91Z2guDQ0KDQ0KICAg QWxsIGlkbml0cyBlcnJvcnMgYW5kIHdhcm5pbmdzIGhhdmUgYmVlbiByZXNvbHZlZC4NDQoNDQoo MTIpIERlc2NyaWJlIGhvdyB0aGUgZG9jdW1lbnQgbWVldHMgYW55IHJlcXVpcmVkIGZvcm1hbCBy ZXZpZXcNDQpjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3RvciwgbWVkaWEgdHlwZSwgYW5k IFVSSSB0eXBlIHJldmlld3MuDQ0KDQ0KICAgTm90IGFwcGxpY2FibGUuIA0NCg0NCigxMykgSGF2 ZSBhbGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXMN DQplaXRoZXIgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPw0NCg0NCiAgIFllcy4NDQoNDQooMTQp IEFyZSB0aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCBhcmUgbm90 IHJlYWR5IGZvcg0NCmFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBz dGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUNDQpyZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBw bGFuIGZvciB0aGVpciBjb21wbGV0aW9uPw0NCg0NCiAgICBOby4gDQ0KDQ0KKDE1KSBBcmUgdGhl cmUgZG93bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3 KT8NDQpJZiBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhl IEFyZWEgRGlyZWN0b3IgaW4NDQp0aGUgTGFzdCBDYWxsIHByb2NlZHVyZS4NDQoNDQogICAgTm8u ICANDQoNDQooMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhl IHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcNDQpSRkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24g dGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQgaW4gdGhlDQ0KYWJzdHJhY3QsIGFuZCBkaXNj dXNzZWQgaW4gdGhlIGludHJvZHVjdGlvbj8gSWYgdGhlIFJGQ3MgYXJlIG5vdCBsaXN0ZWQNDQpp biB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0 byB0aGUgcGFydCBvZg0NCnRoZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRo aXMgZG9jdW1lbnQgdG8gdGhlIG90aGVyIFJGQ3MNDQppcyBkaXNjdXNzZWQuIElmIHRoaXMgaW5m b3JtYXRpb24gaXMgbm90IGluIHRoZSBkb2N1bWVudCwgZXhwbGFpbiB3aHkNDQp0aGUgaW50ZXJl c3RlZCBjb21tdW5pdHkgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5Lg0NCg0NCiAgICBZZXMuIFVw ZGF0ZXMgUkZDIDIzMjggYW5kIFJGQyA1MzQwLiANDQoNDQooMTcpIERlc2NyaWJlIHRoZSBEb2N1 bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucw0NCnNlY3Rp b24sIGVzcGVjaWFsbHkgd2l0aCByZWdhcmQgdG8gaXRzIGNvbnNpc3RlbmN5IHdpdGggdGhlIGJv ZHkgb2YgdGhlDQ0KZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9u cyB0aGF0IHRoZSBkb2N1bWVudCBtYWtlcw0NCmFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcHJv cHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5BIHJlZ2lzdHJpZXMuDQ0KQ29uZmlybSB0aGF0IGFu eSByZWZlcmVuY2VkIElBTkEgcmVnaXN0cmllcyBoYXZlIGJlZW4gY2xlYXJseQ0NCmlkZW50aWZp ZWQuIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGEN DQpkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUg cmVnaXN0cnksIHRoYXQNDQphbGxvY2F0aW9ucyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0 cmF0aW9ucyBhcmUgZGVmaW5lZCwgYW5kIGENDQpyZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcg cmVnaXN0cnkgaGFzIGJlZW4gc3VnZ2VzdGVkIChzZWUgUkZDIDUyMjYpLg0NCg0NCiAgICBUaGlz IGRvY3VtZW50IGRvZXNuJ3QgcmVxdWlyZSBhbnkgSUFOQSBhY3Rpb25zLiBUaGUgb25lIGFkZGVk IGNvZGUNDQogICAgcG9pbnQgZm9yIHRoZSBuZXcgaW50ZXJmYWNlIHR5cGUgaXMgbm90IHBhcnQg b2YgdGhlIHByb3RvY29sIC0gb25seQ0NCiAgICB0aGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9u IHVzZWQgdG8gZGVzY3JpYmVyIHByb3RvY29sIGJlaGF2aW9yLiAgDQ0KDQ0KKDE4KSBMaXN0IGFu eSBuZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvciBmdXR1 cmUNDQphbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElF U0cgd291bGQgZmluZA0NCnVzZWZ1bCBpbiBzZWxlY3RpbmcgdGhlIElBTkEgRXhwZXJ0cyBmb3Ig dGhlc2UgbmV3IHJlZ2lzdHJpZXMuDQ0KDQ0KICAgICBOb25lLiAgDQ0KDQ0KKDE5KSBEZXNjcmli ZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0byB2YWxpZGF0ZQ0N CnNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudCB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBz dWNoIGFzIFhNTCBjb2RlLA0NCkJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuDQ0KDQ0K ICAgICBOb3QgQXBwbGljYWJsZS4gDQ0KDQ0KICANDQo= --_002_3D4F960365A745C7A679A43E2AA0A19Cericssoncom_-- From michael_barnes@usa.net Thu May 10 07:57:15 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D69121F869A for ; Thu, 10 May 2012 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RkBeoG+QL5I for ; Thu, 10 May 2012 07:57:15 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC321F8624 for ; Thu, 10 May 2012 07:57:14 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 091682ACC3C; Thu, 10 May 2012 14:57:11 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 155qeJo6H4320M01; Thu, 10 May 2012 14:57:07 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap02.cms.usa.net [165.212.11.2] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID162qeJo6H5838X01; Thu, 10 May 2012 14:57:07 -0000 X-USANET-Source: 165.212.11.2 IN michael_barnes@usa.net imap02.cms.usa.net X-USANET-MsgId: XID162qeJo6H5838X01 Received: from [10.21.90.85] [128.107.239.233] by imap02.cms.usa.net (ESMTPSA/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTPSA id 830qeJo6H8384M22; Thu, 10 May 2012 14:57:07 -0000 X-USANET-Auth: 128.107.239.233 AUTH michael_barnes@usa.net [10.21.90.85] Message-ID: <4FABD743.4040901@usa.net> Date: Thu, 10 May 2012 07:57:07 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Z-USANET-MsgId: XID830qeJo6H8384X22 Subject: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 10 May 2012 14:57:15 -0000 Hello Folks, Something which is not discussed in RFC5340 is how to treat Inter-Area or External advertisements from an ABR/ASBR which has the R-bit clear in its Router LSA. My initial thinking was that other routers should simply ignore those advertisements. However it later occurred to me that it might be desirable to reach those destinations if they are on links directly connected to the advertising router. And if those Inter-Area or External routes will be installed in the routing tables of other routers, the ABR/ASBR should stop advertising prefixes which are not on its own interfaces. I think this deserves some discussion and we should have consensus so that all routers behave the same way. Regards, Michael From michael_barnes@usa.net Mon May 14 12:05:03 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63421F88BD for ; Mon, 14 May 2012 12:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52olKV9N9iXz for ; Mon, 14 May 2012 12:05:02 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9732321F8763 for ; Mon, 14 May 2012 12:05:02 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id EDA2B134078; Mon, 14 May 2012 19:04:52 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 584qeNTeY6864M02; Mon, 14 May 2012 19:04:50 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap03.cms.usa.net [165.212.11.3] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID584qeNTeY3571X02; Mon, 14 May 2012 19:04:50 -0000 X-USANET-Source: 165.212.11.3 IN michael_barnes@usa.net imap03.cms.usa.net X-USANET-MsgId: XID584qeNTeY3571X02 Received: from web03.cms.usa.net [165.212.8.203] by imap03.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 346qeNTex4144M23; Mon, 14 May 2012 19:04:49 -0000 X-USANET-Auth: 165.212.8.203 AUTO michael_barnes@usa.net web03.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web03.cms.usa.net (USANET web-mailer C8.MAIN.3.83I); Mon, 14 May 2012 19:04:49 -0000 Date: Mon, 14 May 2012 12:04:49 -0700 From: "Michael Barnes" To: X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <894qeNTDx9152S03.1337022289@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID346qeNTeY4144X23 Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 14 May 2012 19:05:03 -0000 Hi Tanmoy, I agree, this is an interesting use case. However, we must be careful to handle it correctly. Consider, for example, when the only path to the forwarding address is through the ASBR which has the R-bit cleared. Route= rs in the same area as the ASBR would be able to determine this without any tro= uble and not use the ASBR for transit. We need to consider that the ASBR may b= e advertising local routes as externals, and these should be reachable via = the ASBR even when the R-bit is clear. If the forwarding address shares the s= ame prefix, then it would also be reachable in this scenario. So how do other= routers determine which external prefixes are reachable, or not, via the = ASBR with the R-bit cleared? In particular, the routers which are in other are= as? I can think of a couple of ways. A simple one would be for the ASBR to advertise the FA with an infinite metric. This would allow routers to calculate another path to the FA, if one is available, while ensuring the= the ASBR itself would not be used as the transit to the FA. While at the same= time allowing reachability to prefixes local to the ASBR, of course the local prefixes would not be advertised with the same FA. = Thanks, Michael ------ Original Message ------ Received: Mon, 14 May 2012 07:20:09 AM PDT From: Tanmoy To: 'Michael Barnes' , ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, = > = > There seems to be at least 1 use case where it would be required to ins= tall > the ASE/NSSA routes advertised by a router with R bit clear. If the ASE/NSSA > routes have a forwarding address, then those destinations may be reacha= ble > directly bypassing the advertising router and could prove to be useful.= > = > Regards, > Tanmoy. > = > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of= > Michael Barnes > Sent: Thursday, May 10, 2012 8:27 PM > To: ospf@ietf.org > Subject: [OSPF] ABR/ASBR with clear R-bit? > = > Hello Folks, > = > Something which is not discussed in RFC5340 is how to treat Inter-Area = > or External advertisements from an ABR/ASBR which has the R-bit clear i= n = > its Router LSA. My initial thinking was that other routers should simpl= y = > ignore those advertisements. > = > However it later occurred to me that it might be desirable to reach = > those destinations if they are on links directly connected to the = > advertising router. And if those Inter-Area or External routes will be = > installed in the routing tables of other routers, the ABR/ASBR should = > stop advertising prefixes which are not on its own interfaces. > = > I think this deserves some discussion and we should have consensus so = > that all routers behave the same way. > = > Regards, > Michael > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From mdubrovs@cisco.com Mon May 14 16:36:17 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E0021F8930 for ; Mon, 14 May 2012 16:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNCijdF8G98J for ; Mon, 14 May 2012 16:36:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85421F892B for ; Mon, 14 May 2012 16:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdubrovs@cisco.com; l=3677; q=dns/txt; s=iport; t=1337038576; x=1338248176; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=snvNKv7as/ZgChBj/kNu8WYHEw6tn4fXyTPftoNjn5M=; b=RA3HwbjPziC1pxnaJlU1ttyWHsIB1MMwTHPaHDiVPzs9fDCiqvYc8759 GAYCrt9Z0qRNocveXBFYzI4NYLtits4Z+qTYNGYZd8qipeX7ittsVA5kr cIuu7AjoM3+PxOI+vbRkF/8JMfyl0WFJ1RnaUosRfa0jN/cd1KYAFIxxH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKSVsU+rRDoG/2dsb2JhbABEs3WBB4IVAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZwQBC5p/n3sEixqFHWMEiGSbcIFpgwk X-IronPort-AV: E=Sophos;i="4.75,590,1330905600"; d="scan'208";a="44787574" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 May 2012 23:36:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4ENaGOw005335; Mon, 14 May 2012 23:36:16 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 16:36:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 16:36:14 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB1055FCC1@xmb-sjc-223.amer.cisco.com> In-Reply-To: <894qeNTDx9152S03.1337022289@web03.cms.usa.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] ABR/ASBR with clear R-bit? Thread-Index: Ac0yBHvEAcUdUtqlTqibKuZXIOMaagAJN1Fw References: <894qeNTDx9152S03.1337022289@web03.cms.usa.net> From: "Mike Dubrovskiy (mdubrovs)" To: "Michael Barnes" , X-OriginalArrivalTime: 14 May 2012 23:36:15.0852 (UTC) FILETIME=[5AE402C0:01CD322A] Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 14 May 2012 23:36:17 -0000 Hi Michael, It seems that there's more than one way to skin a cat. How about this one: Router with R-bit cleared should be area internal router. In case if R-bit is cleared on ABR or ASBR, the router must give up the ABR/ASBR status. Mike -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Michael Barnes Sent: Monday, May 14, 2012 12:05 PM To: tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy, I agree, this is an interesting use case. However, we must be careful to handle it correctly. Consider, for example, when the only path to the forwarding address is through the ASBR which has the R-bit cleared. Routers in the same area as the ASBR would be able to determine this without any trouble and not use the ASBR for transit. We need to consider that the ASBR may be advertising local routes as externals, and these should be reachable via the ASBR even when the R-bit is clear. If the forwarding address shares the same prefix, then it would also be reachable in this scenario. So how do other routers determine which external prefixes are reachable, or not, via the ASBR with the R-bit cleared? In particular, the routers which are in other areas? I can think of a couple of ways. A simple one would be for the ASBR to advertise the FA with an infinite metric. This would allow routers to calculate another path to the FA, if one is available, while ensuring the the ASBR itself would not be used as the transit to the FA. While at the same time allowing reachability to prefixes local to the ASBR, of course the local prefixes would not be advertised with the same FA.=20 Thanks, Michael ------ Original Message ------ Received: Mon, 14 May 2012 07:20:09 AM PDT From: Tanmoy To: 'Michael Barnes' , ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, >=20 > There seems to be at least 1 use case where it would be required to=20 > install the ASE/NSSA routes advertised by a router with R bit clear.=20 > If the ASE/NSSA > routes have a forwarding address, then those destinations may be=20 > reachable directly bypassing the advertising router and could prove to be useful. >=20 > Regards, > Tanmoy. >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 > Of Michael Barnes > Sent: Thursday, May 10, 2012 8:27 PM > To: ospf@ietf.org > Subject: [OSPF] ABR/ASBR with clear R-bit? >=20 > Hello Folks, >=20 > Something which is not discussed in RFC5340 is how to treat Inter-Area > or External advertisements from an ABR/ASBR which has the R-bit clear=20 > in its Router LSA. My initial thinking was that other routers should=20 > simply ignore those advertisements. >=20 > However it later occurred to me that it might be desirable to reach=20 > those destinations if they are on links directly connected to the=20 > advertising router. And if those Inter-Area or External routes will be > installed in the routing tables of other routers, the ABR/ASBR should=20 > stop advertising prefixes which are not on its own interfaces. >=20 > I think this deserves some discussion and we should have consensus so=20 > that all routers behave the same way. >=20 > Regards, > Michael > _______________________________________________ > 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 tanmoy.kundu@huawei.com Tue May 15 06:55:25 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F18921F89CE for ; Tue, 15 May 2012 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9qc0ZrENpqb for ; Tue, 15 May 2012 06:55:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3AD21F89CC for ; Tue, 15 May 2012 06:55:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFY12873; Tue, 15 May 2012 09:55:24 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 06:53:20 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 06:53:19 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Tue, 15 May 2012 21:53:11 +0800 From: Tanmoy To: , 'Michael Barnes' , "'Mike Dubrovskiy (mdubrovs)'" References: <894qeNTDx9152S03.1337022289@web03.cms.usa.net> <6E21698722408147BEA594E073E2B0AB1055FCC1@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB1055FCC1@xmb-sjc-223.amer.cisco.com> Date: Tue, 15 May 2012 19:23:10 +0530 Organization: Htipl Message-ID: <000001cd32a2$10da86e0$328f94a0$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0yBHvEAcUdUtqlTqibKuZXIOMaagAJN1FwAB4k3LA= Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 13:55:25 -0000 Hi Micheal/Mike, @Michael : Considering your suggestion I have one question, during SPF all router would add the Router with R-Bit clear as Stub node. Hence there is no chance where this router being used as transit for forwarding address. @Mike : we shall not consider this router to give up the ABR/ASBR status. As Michael said, the router might need to advertise its own directly connected routes as Inter or ASE/NSSA routes. I have one suggestion, since the Originator will know BEST about the routes its originating, we shall put some restrictions there. Such as.. [1] Router with R-bit clear is allowed to originate AS-External/NSSA LSA for directly connected routes ONLY. [2] Router with R-bit clear is allowed to originate inter aera LSA to other areas for the directly connected routes ONLY. [3] For all other AS-External/NSSA destination where there is a valid Forwarding address can be derived, the LSA should be originated. All other sources MUST NOT be originated by the Router with R-Bit Clear. Thanks, - Tanmoy -----Original Message----- From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] Sent: Tuesday, May 15, 2012 5:06 AM To: Michael Barnes; tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? Hi Michael, It seems that there's more than one way to skin a cat. How about this one: Router with R-bit cleared should be area internal router. In case if R-bit is cleared on ABR or ASBR, the router must give up the ABR/ASBR status. Mike -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Michael Barnes Sent: Monday, May 14, 2012 12:05 PM To: tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy, I agree, this is an interesting use case. However, we must be careful to handle it correctly. Consider, for example, when the only path to the forwarding address is through the ASBR which has the R-bit cleared. Routers in the same area as the ASBR would be able to determine this without any trouble and not use the ASBR for transit. We need to consider that the ASBR may be advertising local routes as externals, and these should be reachable via the ASBR even when the R-bit is clear. If the forwarding address shares the same prefix, then it would also be reachable in this scenario. So how do other routers determine which external prefixes are reachable, or not, via the ASBR with the R-bit cleared? In particular, the routers which are in other areas? I can think of a couple of ways. A simple one would be for the ASBR to advertise the FA with an infinite metric. This would allow routers to calculate another path to the FA, if one is available, while ensuring the the ASBR itself would not be used as the transit to the FA. While at the same time allowing reachability to prefixes local to the ASBR, of course the local prefixes would not be advertised with the same FA. Thanks, Michael ------ Original Message ------ Received: Mon, 14 May 2012 07:20:09 AM PDT From: Tanmoy To: 'Michael Barnes' , ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, > > There seems to be at least 1 use case where it would be required to > install the ASE/NSSA routes advertised by a router with R bit clear. > If the ASE/NSSA > routes have a forwarding address, then those destinations may be > reachable directly bypassing the advertising router and could prove to be useful. > > Regards, > Tanmoy. > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of Michael Barnes > Sent: Thursday, May 10, 2012 8:27 PM > To: ospf@ietf.org > Subject: [OSPF] ABR/ASBR with clear R-bit? > > Hello Folks, > > Something which is not discussed in RFC5340 is how to treat Inter-Area > or External advertisements from an ABR/ASBR which has the R-bit clear > in its Router LSA. My initial thinking was that other routers should > simply ignore those advertisements. > > However it later occurred to me that it might be desirable to reach > those destinations if they are on links directly connected to the > advertising router. And if those Inter-Area or External routes will be > installed in the routing tables of other routers, the ABR/ASBR should > stop advertising prefixes which are not on its own interfaces. > > I think this deserves some discussion and we should have consensus so > that all routers behave the same way. > > Regards, > Michael > _______________________________________________ > 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 michael_barnes@usa.net Tue May 15 08:02:01 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0338221F893E for ; Tue, 15 May 2012 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVRSHKb9Nxr4 for ; Tue, 15 May 2012 08:02:00 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24821F8930 for ; Tue, 15 May 2012 08:02:00 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id E3B0F1344E4; Tue, 15 May 2012 15:01:56 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 828qeoPB22464M02; Tue, 15 May 2012 15:01:53 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap02.cms.usa.net [165.212.11.2] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID828qeoPB28531X02; Tue, 15 May 2012 15:01:53 -0000 X-USANET-Source: 165.212.11.2 IN michael_barnes@usa.net imap02.cms.usa.net X-USANET-MsgId: XID828qeoPB28531X02 Received: from web02.cms.usa.net [165.212.8.202] by imap02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 406qeoPB14592M22; Tue, 15 May 2012 15:01:52 -0000 X-USANET-Auth: 165.212.8.202 AUTO michael_barnes@usa.net web02.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web02.cms.usa.net (USANET web-mailer C8.MAIN.3.83I); Tue, 15 May 2012 15:01:52 -0000 Date: Tue, 15 May 2012 08:01:52 -0700 From: "Michael Barnes" To: "Mike Dubrovskiy (mdubrovs)" , "Michael Barnes" , X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <566qeoPa19536S02.1337094112@web02.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID406qeoPB24592X22 Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 15:02:01 -0000 Hi Mike, Yes, there are a number of possible ways to address this. This would be one way to go about it. However, I don't think it is desira= ble. Especially when considering that in some cases operators like to advertis= e prefixes for local interfaces as external routes on spoke routers. They c= ould use the R-bit to make the spoke not pass transit traffic. If we chose thi= s option, then all prefixes would have to be advertised as intra-area prefi= xes. Therefore I'm reluctant to use this method. Regards, Michael ------ Original Message ------ Received: Mon, 14 May 2012 04:36:26 PM PDT From: "Mike Dubrovskiy (mdubrovs)" To: "Michael Barnes" , C= c: Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, > = > It seems that there's more than one way to skin a cat. > = > How about this one: > = > Router with R-bit cleared should be area internal router. > In case if R-bit is cleared on ABR or ASBR, the router must give up the= > ABR/ASBR status. > = > Mike > = > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of= > Michael Barnes > Sent: Monday, May 14, 2012 12:05 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > = > Hi Tanmoy, > = > I agree, this is an interesting use case. However, we must be careful t= o > handle it correctly. Consider, for example, when the only path to the > forwarding address is through the ASBR which has the R-bit cleared. > Routers in the same area as the ASBR would be able to determine this > without any trouble and not use the ASBR for transit. We need to > consider that the ASBR may be advertising local routes as externals, an= d > these should be reachable via the ASBR even when the R-bit is clear. If= > the forwarding address shares the same prefix, then it would also be > reachable in this scenario. So how do other routers determine which > external prefixes are reachable, or not, via the ASBR with the R-bit > cleared? In particular, the routers which are in other areas? > = > I can think of a couple of ways. A simple one would be for the ASBR to > advertise the FA with an infinite metric. This would allow routers to > calculate another path to the FA, if one is available, while ensuring > the the ASBR itself would not be used as the transit to the FA. While a= t > the same time allowing reachability to prefixes local to the ASBR, of > course the local prefixes would not be advertised with the same FA. = > = > Thanks, > Michael > = > ------ Original Message ------ > Received: Mon, 14 May 2012 07:20:09 AM PDT > From: Tanmoy > To: 'Michael Barnes' , ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > = > > Hi Michael, > > = > > There seems to be at least 1 use case where it would be required to = > > install the ASE/NSSA routes advertised by a router with R bit clear. = > > If the > ASE/NSSA > > routes have a forwarding address, then those destinations may be = > > reachable directly bypassing the advertising router and could prove t= o > be useful. > > = > > Regards, > > Tanmoy. > > = > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = > > Of Michael Barnes > > Sent: Thursday, May 10, 2012 8:27 PM > > To: ospf@ietf.org > > Subject: [OSPF] ABR/ASBR with clear R-bit? > > = > > Hello Folks, > > = > > Something which is not discussed in RFC5340 is how to treat Inter-Are= a > = > > or External advertisements from an ABR/ASBR which has the R-bit clear= = > > in its Router LSA. My initial thinking was that other routers should = > > simply ignore those advertisements. > > = > > However it later occurred to me that it might be desirable to reach = > > those destinations if they are on links directly connected to the = > > advertising router. And if those Inter-Area or External routes will b= e > = > > installed in the routing tables of other routers, the ABR/ASBR should= = > > stop advertising prefixes which are not on its own interfaces. > > = > > I think this deserves some discussion and we should have consensus so= = > > that all routers behave the same way. > > = > > Regards, > > Michael > > _______________________________________________ > > 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 michael_barnes@usa.net Tue May 15 08:07:46 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA721F8607 for ; Tue, 15 May 2012 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Jo-YMwFyjK for ; Tue, 15 May 2012 08:07:45 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id 256D221F8468 for ; Tue, 15 May 2012 08:07:28 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 6EE332ACB8E; Tue, 15 May 2012 15:07:25 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 711qeoPHw3520M01; Tue, 15 May 2012 15:07:22 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap02.cms.usa.net [165.212.11.2] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID718qeoPHw7422X01; Tue, 15 May 2012 15:07:22 -0000 X-USANET-Source: 165.212.11.2 IN michael_barnes@usa.net imap02.cms.usa.net X-USANET-MsgId: XID718qeoPHw7422X01 Received: from web03.cms.usa.net [165.212.8.203] by imap02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 010qeoPHw9392M22; Tue, 15 May 2012 15:07:22 -0000 X-USANET-Auth: 165.212.8.203 AUTO michael_barnes@usa.net web03.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web03.cms.usa.net (USANET web-mailer C8.MAIN.3.83I); Tue, 15 May 2012 15:07:22 -0000 Date: Tue, 15 May 2012 08:07:22 -0700 From: "Michael Barnes" To: X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <882qeoPgw7360S03.1337094442@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID010qeoPHw9392X22 Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 15:07:46 -0000 Hi Tanmoy, ------ Original Message ------ Received: Mon, 14 May 2012 11:24:00 PM PDT From: Tanmoy To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Barnes'= Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Micheal/Mike, = > = > @Michael : Considering your suggestion I have one question, during SPF = all > router would add the Router with R-Bit clear as Stub node. Hence there = is no > chance where this router being used as transit for forwarding address. = This is true when the router is in the same area as the ASBR. However, if= the router is in another area then it does not have a way to know if the inter-area route transits the ASBR or is reachable through another router= in that area. > @Mike : we shall not consider this router to give up the ABR/ASBR statu= s. As > Michael said, the router might need to advertise its own directly conne= cted > routes as Inter or ASE/NSSA routes. = > = > I have one suggestion, since the Originator will know BEST about the ro= utes > its originating, we shall put some restrictions there. = > Such as.. > [1] Router with R-bit clear is allowed to originate AS-External/NSSA L= SA > for directly connected routes ONLY. = > [2] Router with R-bit clear is allowed to originate inter aera LSA to other > areas for the directly connected routes ONLY. = The two above are essentially the same as what I suggested in my first e-= mail of the thread. :-) > [3] For all other AS-External/NSSA destination where there is a valid > Forwarding address can be derived, the LSA should be originated. = > All other sources MUST NOT be originated by the Router with R-Bit Clear= =2E = How does the ASBR know if the FA is reachable not via itself? Should it d= o special type of SPF calculation to see if there is some other path? Thanks, Michael > Thanks, > - Tanmoy > = > = > = > = > = > = > -----Original Message----- > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] = > Sent: Tuesday, May 15, 2012 5:06 AM > To: Michael Barnes; tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > = > Hi Michael, > = > It seems that there's more than one way to skin a cat. > = > How about this one: > = > Router with R-bit cleared should be area internal router. > In case if R-bit is cleared on ABR or ASBR, the router must give up the= > ABR/ASBR status. > = > Mike > = > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of= > Michael Barnes > Sent: Monday, May 14, 2012 12:05 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > = > Hi Tanmoy, > = > I agree, this is an interesting use case. However, we must be careful t= o > handle it correctly. Consider, for example, when the only path to the > forwarding address is through the ASBR which has the R-bit cleared. > Routers in the same area as the ASBR would be able to determine this > without any trouble and not use the ASBR for transit. We need to > consider that the ASBR may be advertising local routes as externals, an= d > these should be reachable via the ASBR even when the R-bit is clear. If= > the forwarding address shares the same prefix, then it would also be > reachable in this scenario. So how do other routers determine which > external prefixes are reachable, or not, via the ASBR with the R-bit > cleared? In particular, the routers which are in other areas? > = > I can think of a couple of ways. A simple one would be for the ASBR to > advertise the FA with an infinite metric. This would allow routers to > calculate another path to the FA, if one is available, while ensuring > the the ASBR itself would not be used as the transit to the FA. While a= t > the same time allowing reachability to prefixes local to the ASBR, of > course the local prefixes would not be advertised with the same FA. = > = > Thanks, > Michael > = > ------ Original Message ------ > Received: Mon, 14 May 2012 07:20:09 AM PDT > From: Tanmoy > To: 'Michael Barnes' , ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > = > > Hi Michael, > > = > > There seems to be at least 1 use case where it would be required to = > > install the ASE/NSSA routes advertised by a router with R bit clear. = > > If the > ASE/NSSA > > routes have a forwarding address, then those destinations may be = > > reachable directly bypassing the advertising router and could prove t= o > be useful. > > = > > Regards, > > Tanmoy. > > = > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = > > Of Michael Barnes > > Sent: Thursday, May 10, 2012 8:27 PM > > To: ospf@ietf.org > > Subject: [OSPF] ABR/ASBR with clear R-bit? > > = > > Hello Folks, > > = > > Something which is not discussed in RFC5340 is how to treat Inter-Are= a > = > > or External advertisements from an ABR/ASBR which has the R-bit clear= = > > in its Router LSA. My initial thinking was that other routers should = > > simply ignore those advertisements. > > = > > However it later occurred to me that it might be desirable to reach = > > those destinations if they are on links directly connected to the = > > advertising router. And if those Inter-Area or External routes will b= e > = > > installed in the routing tables of other routers, the ABR/ASBR should= = > > stop advertising prefixes which are not on its own interfaces. > > = > > I think this deserves some discussion and we should have consensus so= = > > that all routers behave the same way. > > = > > Regards, > > Michael > > _______________________________________________ > > 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 tanmoy.kundu@huawei.com Thu May 17 07:03:19 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCBC21F85C6 for ; Thu, 17 May 2012 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=1.964, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeXApBMg7p0i for ; Thu, 17 May 2012 07:03:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9D79A21F853C for ; Thu, 17 May 2012 07:03:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFZ93781; Thu, 17 May 2012 10:03:13 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 06:59:11 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 06:59:16 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Thu, 17 May 2012 21:59:09 +0800 From: Tanmoy To: References: <882qeoPgw7360S03.1337094442@web03.cms.usa.net> In-Reply-To: <882qeoPgw7360S03.1337094442@web03.cms.usa.net> Date: Thu, 17 May 2012 19:29:08 +0530 Organization: Htipl Message-ID: <000001cd3435$3aee01c0$b0ca0540$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0yrHRE+rrsCF7bT2S/v8hNeqvstwAf9QyA Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:03:19 -0000 Hi Michael, A couple of ideas... Firstly we should prevent that other routers do not use the R-bit clear Router as transit for reaching the FA. To ensure this, the Router with R-bit clear MUST not originate any inter-area network prefixes. It is allowed to originate only inter-area host prefixes (128 prefix length) that correspond to its own interface addresses. [This make sense too since this router does not want to service transit traffic so there is no need to advertise the attached networks]. Additionally : The R-bit clear ASBR can originate the AS-external route only when there is a good chance that there is an alternate path to the FA. To do this, the ASBR can examine the network LSA of the interface corresponding to the FA and check that there is at least one other router with the R-bit set, in which case the LSA can be originated. This part is fully optional and if not followed, may result in AS-External LSAs that are not usable. Anyway, the solution presented here is simple and not foolproof for all cases (e.g. there is another router with the R-bit set, but it is reachable to a set of routers in the topology only through the router with R-bit clear). More robust but complex solutions are possible ;-) With these restrictions/conditions, the following cases need to be examined: Case 1 : R-bit Clear router is the only ABR for the other area. Based on the restriction proposed, the R-Bit clear router will originate only directly interface routes as Inter-area routes(with 128 prefix length). This will ensure the other router cannot use it as a transit to reach the FA, since the network is not visible at all. Case 2 : There is another ABR in the area. In this case, since the other ABR router will originate the inter-area route for the FA's network prefix, all routers will consider the other router as the transit router and will calculate reachability only through the other router. Regards, - Tanmoy -----Original Message----- From: Michael Barnes [mailto:michael_barnes@usa.net] Sent: Tuesday, May 15, 2012 8:37 PM To: tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy, ------ Original Message ------ Received: Mon, 14 May 2012 11:24:00 PM PDT From: Tanmoy To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Barnes' Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Micheal/Mike, > > @Michael : Considering your suggestion I have one question, during SPF all > router would add the Router with R-Bit clear as Stub node. Hence there is no > chance where this router being used as transit for forwarding address. This is true when the router is in the same area as the ASBR. However, if the router is in another area then it does not have a way to know if the inter-area route transits the ASBR or is reachable through another router in that area. > @Mike : we shall not consider this router to give up the ABR/ASBR status. As > Michael said, the router might need to advertise its own directly connected > routes as Inter or ASE/NSSA routes. > > I have one suggestion, since the Originator will know BEST about the routes > its originating, we shall put some restrictions there. > Such as.. > [1] Router with R-bit clear is allowed to originate AS-External/NSSA LSA > for directly connected routes ONLY. > [2] Router with R-bit clear is allowed to originate inter aera LSA to other > areas for the directly connected routes ONLY. The two above are essentially the same as what I suggested in my first e-mail of the thread. :-) > [3] For all other AS-External/NSSA destination where there is a valid > Forwarding address can be derived, the LSA should be originated. > All other sources MUST NOT be originated by the Router with R-Bit Clear. How does the ASBR know if the FA is reachable not via itself? Should it do special type of SPF calculation to see if there is some other path? Thanks, Michael > Thanks, > - Tanmoy > > > > > > > -----Original Message----- > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] > Sent: Tuesday, May 15, 2012 5:06 AM > To: Michael Barnes; tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > Hi Michael, > > It seems that there's more than one way to skin a cat. > > How about this one: > > Router with R-bit cleared should be area internal router. > In case if R-bit is cleared on ABR or ASBR, the router must give up the > ABR/ASBR status. > > Mike > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Michael Barnes > Sent: Monday, May 14, 2012 12:05 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > > Hi Tanmoy, > > I agree, this is an interesting use case. However, we must be careful to > handle it correctly. Consider, for example, when the only path to the > forwarding address is through the ASBR which has the R-bit cleared. > Routers in the same area as the ASBR would be able to determine this > without any trouble and not use the ASBR for transit. We need to > consider that the ASBR may be advertising local routes as externals, and > these should be reachable via the ASBR even when the R-bit is clear. If > the forwarding address shares the same prefix, then it would also be > reachable in this scenario. So how do other routers determine which > external prefixes are reachable, or not, via the ASBR with the R-bit > cleared? In particular, the routers which are in other areas? > > I can think of a couple of ways. A simple one would be for the ASBR to > advertise the FA with an infinite metric. This would allow routers to > calculate another path to the FA, if one is available, while ensuring > the the ASBR itself would not be used as the transit to the FA. While at > the same time allowing reachability to prefixes local to the ASBR, of > course the local prefixes would not be advertised with the same FA. > > Thanks, > Michael > > ------ Original Message ------ > Received: Mon, 14 May 2012 07:20:09 AM PDT > From: Tanmoy > To: 'Michael Barnes' , ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > Hi Michael, > > > > There seems to be at least 1 use case where it would be required to > > install the ASE/NSSA routes advertised by a router with R bit clear. > > If the > ASE/NSSA > > routes have a forwarding address, then those destinations may be > > reachable directly bypassing the advertising router and could prove to > be useful. > > > > Regards, > > Tanmoy. > > > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > > Of Michael Barnes > > Sent: Thursday, May 10, 2012 8:27 PM > > To: ospf@ietf.org > > Subject: [OSPF] ABR/ASBR with clear R-bit? > > > > Hello Folks, > > > > Something which is not discussed in RFC5340 is how to treat Inter-Area > > > or External advertisements from an ABR/ASBR which has the R-bit clear > > in its Router LSA. My initial thinking was that other routers should > > simply ignore those advertisements. > > > > However it later occurred to me that it might be desirable to reach > > those destinations if they are on links directly connected to the > > advertising router. And if those Inter-Area or External routes will be > > > installed in the routing tables of other routers, the ABR/ASBR should > > stop advertising prefixes which are not on its own interfaces. > > > > I think this deserves some discussion and we should have consensus so > > that all routers behave the same way. > > > > Regards, > > Michael > > _______________________________________________ > > 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 tanmoy.kundu@huawei.com Thu May 17 07:09:44 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ADB21F866D for ; Thu, 17 May 2012 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=1.964, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDO1AvI4o942 for ; Thu, 17 May 2012 07:09:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6530821F8650 for ; Thu, 17 May 2012 07:09:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGG90829; Thu, 17 May 2012 10:09:44 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 07:06:59 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 07:07:04 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server id 14.1.323.3; Thu, 17 May 2012 22:07:00 +0800 From: Tanmoy To: Date: Thu, 17 May 2012 19:36:59 +0530 Organization: Htipl Message-ID: <000101cd3436$542176d0$fc646470$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0yrHRE+rrsCF7bT2S/v8hNeqvstwAf9QyAAEJ+slA= Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:09:45 -0000 Hi Michael, A couple of ideas... Firstly we should prevent that other routers do not use the R-bit clear Router as transit for reaching the FA. To ensure this, the Router with R-bit clear MUST not originate any inter-area network prefixes. It is allowed to originate only inter-area host prefixes (128 prefix length) that correspond to its own interface addresses. [This make sense too since this router does not want to service transit traffic so there is no need to advertise the attached networks]. Additionally : The R-bit clear ASBR can originate the AS-external route only when there is a good chance that there is an alternate path to the FA. To do this, the ASBR can examine the network LSA of the interface corresponding to the FA and check that there is at least one other router with the R-bit set, in which case the LSA can be originated. This part is fully optional and if not followed, may result in AS-External LSAs that are not usable. Anyway, the solution presented here is simple and not foolproof for all cases (e.g. there is another router with the R-bit set, but it is reachable to a set of routers in the topology only through the router with R-bit clear). More robust but complex solutions are possible ;-) With these restrictions/conditions, the following cases need to be examined: Case 1 : R-bit Clear router is the only ABR for the other area. Based on the restriction proposed, the R-Bit clear router will originate only directly interface routes as Inter-area routes(with 128 prefix length). This will ensure the other router cannot use it as a transit to reach the FA, since the network is not visible at all. Case 2 : There is another ABR in the area. In this case, since the other ABR router will originate the inter-area route for the FA's network prefix, all routers will consider the other router as the transit router and will calculate reachability only through the other router. Regards, - Tanmoy -----Original Message----- From: Michael Barnes [mailto:michael_barnes@usa.net] Sent: Tuesday, May 15, 2012 8:37 PM To: tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy, ------ Original Message ------ Received: Mon, 14 May 2012 11:24:00 PM PDT From: Tanmoy To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Barnes' Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Micheal/Mike, > > @Michael : Considering your suggestion I have one question, during SPF all > router would add the Router with R-Bit clear as Stub node. Hence there is no > chance where this router being used as transit for forwarding address. This is true when the router is in the same area as the ASBR. However, if the router is in another area then it does not have a way to know if the inter-area route transits the ASBR or is reachable through another router in that area. > @Mike : we shall not consider this router to give up the ABR/ASBR status. As > Michael said, the router might need to advertise its own directly connected > routes as Inter or ASE/NSSA routes. > > I have one suggestion, since the Originator will know BEST about the routes > its originating, we shall put some restrictions there. > Such as.. > [1] Router with R-bit clear is allowed to originate AS-External/NSSA LSA > for directly connected routes ONLY. > [2] Router with R-bit clear is allowed to originate inter aera LSA to other > areas for the directly connected routes ONLY. The two above are essentially the same as what I suggested in my first e-mail of the thread. :-) > [3] For all other AS-External/NSSA destination where there is a valid > Forwarding address can be derived, the LSA should be originated. > All other sources MUST NOT be originated by the Router with R-Bit Clear. How does the ASBR know if the FA is reachable not via itself? Should it do special type of SPF calculation to see if there is some other path? Thanks, Michael > Thanks, > - Tanmoy > > > > > > > -----Original Message----- > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] > Sent: Tuesday, May 15, 2012 5:06 AM > To: Michael Barnes; tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > Hi Michael, > > It seems that there's more than one way to skin a cat. > > How about this one: > > Router with R-bit cleared should be area internal router. > In case if R-bit is cleared on ABR or ASBR, the router must give up the > ABR/ASBR status. > > Mike > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Michael Barnes > Sent: Monday, May 14, 2012 12:05 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > > Hi Tanmoy, > > I agree, this is an interesting use case. However, we must be careful to > handle it correctly. Consider, for example, when the only path to the > forwarding address is through the ASBR which has the R-bit cleared. > Routers in the same area as the ASBR would be able to determine this > without any trouble and not use the ASBR for transit. We need to > consider that the ASBR may be advertising local routes as externals, and > these should be reachable via the ASBR even when the R-bit is clear. If > the forwarding address shares the same prefix, then it would also be > reachable in this scenario. So how do other routers determine which > external prefixes are reachable, or not, via the ASBR with the R-bit > cleared? In particular, the routers which are in other areas? > > I can think of a couple of ways. A simple one would be for the ASBR to > advertise the FA with an infinite metric. This would allow routers to > calculate another path to the FA, if one is available, while ensuring > the the ASBR itself would not be used as the transit to the FA. While at > the same time allowing reachability to prefixes local to the ASBR, of > course the local prefixes would not be advertised with the same FA. > > Thanks, > Michael > > ------ Original Message ------ > Received: Mon, 14 May 2012 07:20:09 AM PDT > From: Tanmoy > To: 'Michael Barnes' , ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > Hi Michael, > > > > There seems to be at least 1 use case where it would be required to > > install the ASE/NSSA routes advertised by a router with R bit clear. > > If the > ASE/NSSA > > routes have a forwarding address, then those destinations may be > > reachable directly bypassing the advertising router and could prove to > be useful. > > > > Regards, > > Tanmoy. > > > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > > Of Michael Barnes > > Sent: Thursday, May 10, 2012 8:27 PM > > To: ospf@ietf.org > > Subject: [OSPF] ABR/ASBR with clear R-bit? > > > > Hello Folks, > > > > Something which is not discussed in RFC5340 is how to treat Inter-Area > > > or External advertisements from an ABR/ASBR which has the R-bit clear > > in its Router LSA. My initial thinking was that other routers should > > simply ignore those advertisements. > > > > However it later occurred to me that it might be desirable to reach > > those destinations if they are on links directly connected to the > > advertising router. And if those Inter-Area or External routes will be > > > installed in the routing tables of other routers, the ABR/ASBR should > > stop advertising prefixes which are not on its own interfaces. > > > > I think this deserves some discussion and we should have consensus so > > that all routers behave the same way. > > > > Regards, > > Michael > > _______________________________________________ > > 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 tanmoy.kundu@huawei.com Thu May 17 07:28:25 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C749821F85F0 for ; Thu, 17 May 2012 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=1.785, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfzWIWBdJ0qC for ; Thu, 17 May 2012 07:28:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F521F85D2 for ; Thu, 17 May 2012 07:28:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGG92213; Thu, 17 May 2012 10:28:24 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 07:25:45 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 May 2012 07:25:43 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server id 14.1.323.3; Thu, 17 May 2012 22:25:37 +0800 From: Tanmoy To: 'Michael Barnes' References: <882qeoPgw7360S03.1337094442@web03.cms.usa.net> In-Reply-To: <882qeoPgw7360S03.1337094442@web03.cms.usa.net> Date: Thu, 17 May 2012 19:55:36 +0530 Organization: Htipl Message-ID: <000201cd3438$edf5bc10$c9e13430$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0yrHRE+rrsCF7bT2S/v8hNeqvstwBjF7CQ Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Cc: ospf@ietf.org Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:28:25 -0000 Hi Michael, A couple of ideas... Firstly we should prevent that other routers do not use the R-bit clear Router as transit for reaching the FA. To ensure this, the Router with R-bit clear MUST not originate any inter-area network prefixes. It is allowed to originate only inter-area host prefixes (128 prefix length) that correspond to its own interface addresses. [This make sense too since this router does not want to service transit traffic so there is no need to advertise the attached networks]. Additionally : The R-bit clear ASBR can originate the AS-external route only when there is a good chance that there is an alternate path to the FA. To do this, the ASBR can examine the network LSA of the interface corresponding to the FA and check that there is at least one other router with the R-bit set, in which case the LSA can be originated. This part is fully optional and if not followed, may result in AS-External LSAs that are not usable. Anyway, the solution presented here is simple and not foolproof for all cases (e.g. there is another router with the R-bit set, but it is reachable to a set of routers in the topology only through the router with R-bit clear). More robust but complex solutions are possible ;-) With these restrictions/conditions, the following cases need to be examined: Case 1 : R-bit Clear router is the only ABR for the other area. Based on the restriction proposed, the R-Bit clear router will originate only directly interface routes as Inter-area routes(with 128 prefix length). This will ensure the other router cannot use it as a transit to reach the FA, since the network is not visible at all. Case 2 : There is another ABR in the area. In this case, since the other ABR router will originate the inter-area route for the FA's network prefix, all routers will consider the other router as the transit router and will calculate reachability only through the other router. Regards, - Tanmoy -----Original Message----- From: Michael Barnes [mailto:michael_barnes@usa.net] Sent: Tuesday, May 15, 2012 8:37 PM To: tanmoy.kundu@huawei.com Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy, ------ Original Message ------ Received: Mon, 14 May 2012 11:24:00 PM PDT From: Tanmoy To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Barnes' Cc: ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Micheal/Mike, > > @Michael : Considering your suggestion I have one question, during SPF all > router would add the Router with R-Bit clear as Stub node. Hence there is no > chance where this router being used as transit for forwarding address. This is true when the router is in the same area as the ASBR. However, if the router is in another area then it does not have a way to know if the inter-area route transits the ASBR or is reachable through another router in that area. > @Mike : we shall not consider this router to give up the ABR/ASBR status. As > Michael said, the router might need to advertise its own directly connected > routes as Inter or ASE/NSSA routes. > > I have one suggestion, since the Originator will know BEST about the routes > its originating, we shall put some restrictions there. > Such as.. > [1] Router with R-bit clear is allowed to originate AS-External/NSSA LSA > for directly connected routes ONLY. > [2] Router with R-bit clear is allowed to originate inter aera LSA to other > areas for the directly connected routes ONLY. The two above are essentially the same as what I suggested in my first e-mail of the thread. :-) > [3] For all other AS-External/NSSA destination where there is a valid > Forwarding address can be derived, the LSA should be originated. > All other sources MUST NOT be originated by the Router with R-Bit Clear. How does the ASBR know if the FA is reachable not via itself? Should it do special type of SPF calculation to see if there is some other path? Thanks, Michael > Thanks, > - Tanmoy > > > > > > > -----Original Message----- > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] > Sent: Tuesday, May 15, 2012 5:06 AM > To: Michael Barnes; tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > Hi Michael, > > It seems that there's more than one way to skin a cat. > > How about this one: > > Router with R-bit cleared should be area internal router. > In case if R-bit is cleared on ABR or ASBR, the router must give up the > ABR/ASBR status. > > Mike > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Michael Barnes > Sent: Monday, May 14, 2012 12:05 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > > Hi Tanmoy, > > I agree, this is an interesting use case. However, we must be careful to > handle it correctly. Consider, for example, when the only path to the > forwarding address is through the ASBR which has the R-bit cleared. > Routers in the same area as the ASBR would be able to determine this > without any trouble and not use the ASBR for transit. We need to > consider that the ASBR may be advertising local routes as externals, and > these should be reachable via the ASBR even when the R-bit is clear. If > the forwarding address shares the same prefix, then it would also be > reachable in this scenario. So how do other routers determine which > external prefixes are reachable, or not, via the ASBR with the R-bit > cleared? In particular, the routers which are in other areas? > > I can think of a couple of ways. A simple one would be for the ASBR to > advertise the FA with an infinite metric. This would allow routers to > calculate another path to the FA, if one is available, while ensuring > the the ASBR itself would not be used as the transit to the FA. While at > the same time allowing reachability to prefixes local to the ASBR, of > course the local prefixes would not be advertised with the same FA. > > Thanks, > Michael > > ------ Original Message ------ > Received: Mon, 14 May 2012 07:20:09 AM PDT > From: Tanmoy > To: 'Michael Barnes' , ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > Hi Michael, > > > > There seems to be at least 1 use case where it would be required to > > install the ASE/NSSA routes advertised by a router with R bit clear. > > If the > ASE/NSSA > > routes have a forwarding address, then those destinations may be > > reachable directly bypassing the advertising router and could prove to > be useful. > > > > Regards, > > Tanmoy. > > > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > > Of Michael Barnes > > Sent: Thursday, May 10, 2012 8:27 PM > > To: ospf@ietf.org > > Subject: [OSPF] ABR/ASBR with clear R-bit? > > > > Hello Folks, > > > > Something which is not discussed in RFC5340 is how to treat Inter-Area > > > or External advertisements from an ABR/ASBR which has the R-bit clear > > in its Router LSA. My initial thinking was that other routers should > > simply ignore those advertisements. > > > > However it later occurred to me that it might be desirable to reach > > those destinations if they are on links directly connected to the > > advertising router. And if those Inter-Area or External routes will be > > > installed in the routing tables of other routers, the ABR/ASBR should > > stop advertising prefixes which are not on its own interfaces. > > > > I think this deserves some discussion and we should have consensus so > > that all routers behave the same way. > > > > Regards, > > Michael > > _______________________________________________ > > 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 Mon May 28 13:19:19 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EB21F86A2 for ; Mon, 28 May 2012 13:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q2vzxuFIJEk for ; Mon, 28 May 2012 13:19:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6E821F8674 for ; Mon, 28 May 2012 13:19:17 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4SKIufg012593; Mon, 28 May 2012 15:19:17 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 28 May 2012 16:19:11 -0400 From: Acee Lindem To: OSPF List Date: Mon, 28 May 2012 16:19:08 -0400 Thread-Topic: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac09DyQnqTFj1+/PQ86sYeXCgFf1Tw== Message-ID: <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4--848103914"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Jari Arkko Subject: [OSPF] Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 28 May 2012 20:19:19 -0000 --Apple-Mail-4--848103914 Content-Type: multipart/alternative; boundary=Apple-Mail-3--848103930 --Apple-Mail-3--848103930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as a Draft Author: This version includes additions based on comments received at IETF 83. = Section 5.1 clarifies the detection of a neighbor with a duplicate = Router-ID to exclude the case where multiple router interfaces are = connected to the same link. Section 5.4 was added to mitigate the = effects of a duplicate OSPFv3 Router-ID in the OSPFv3 routing domain = prior to duplicate Router-ID resolution.=20 Additionally, we received a suggestion from Alvaro Retana to not use an = reserved OSPFv3 instance ID for auto-configured routers. Rather, allow = OSPFv3 auto-configured routers to use the default OSPFv3 instance ID and = automatically join an existing non-autoconfigured OSPFv3 routing domain. = I see three possible alternatives: 1. Reject the suggestion. The alternate OSPFv3 instance ID was added = specifically to prevent this.=20 2. Adopt the suggestion and remove the reserved instance ID. The = security considerations now recommend that implementation provide the = capability to configure a single key.=20 3. Add an applicability statement indicating that an implementation = MAY use the default OSPFv3 instance if the network where the = implementation is deployed requires incorporation into an existing = OSPFv3 network.=20 Please provide your thoughts on this issue.=20 Thanks, Acee Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT > To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt >=20 > A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has = been successfully submitted by Acee Lindem and posted to the IETF = repository. >=20 > Filename: draft-acee-ospf-ospfv3-autoconfig > Revision: 02 > Title: OSPFv3 Auto-Configuration > Creation date: 2012-05-28 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be = self-configuring. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-3--848103930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: May 28, 2012 3:41:15 PM EDT
To: Acee Lindem <acee.lindem@ericsson.com><= br>
Subject: New Version = Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt

A = new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been = successfully submitted by Acee Lindem and posted to the IETF = repository.

Filename: = draft-acee-ospf-ospfv3-autoconfig
Revision: = 02
Title: = = OSPFv3 Auto-Configuration
Creation date: = 2012-05-28
WG ID: Individual Submission
Number = of pages: 14

Abstract:
  OSPFv3 is a candidate for = deployments in environments where auto-
  configuration is = a requirement.  One such environment is the IPv6
=   home network where users expect to simply plug in a router = and have
  it automatically use OSPFv3 for intra-domain = routing.  This document
  describes the necessary = mechanisms for OSPFv3 to be self-configuring.




The = IETF Secretariat

= --Apple-Mail-3--848103930-- --Apple-Mail-4--848103914 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyODIwMTkwOVowIwYJKoZI hvcNAQkEMRYEFMzsAGQiSinfL2TmgLwsY6n5qkZ8MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgGOIVERz17AhgZYgh2cnXd6Debc7ePmndvq5zbNzybl8nCcAVnxBzQ4XoTflXWgi 38MqApwK8vVg1Xqc8MeHHSUYNHN919QawJjRxl90wd54ydl0P3EZ4CUa6PqDcLyuGh/5+/vMWxlE 0qaiWe/CJ7IopOLUVetnS+1wSzcefzVaAAAAAAAA --Apple-Mail-4--848103914-- From acee.lindem@ericsson.com Mon May 28 13:24:30 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435C521F86BD for ; Mon, 28 May 2012 13:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9zq9pwMJTn5 for ; Mon, 28 May 2012 13:24:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 584E421F86B1 for ; Mon, 28 May 2012 13:24:29 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4SKORTX013154 for ; Mon, 28 May 2012 15:24:28 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 28 May 2012 16:24:23 -0400 From: Acee Lindem To: OSPF List Date: Mon, 28 May 2012 16:24:21 -0400 Thread-Topic: OSPF WG Adoption of OSPFv3 Auto-Configuration as a WG Document Thread-Index: Ac09D95rYxjDiK8xQAaB34i7QEkSBg== Message-ID: References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-6--847791336"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] OSPF WG Adoption of OSPFv3 Auto-Configuration as a WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 28 May 2012 20:24:30 -0000 --Apple-Mail-6--847791336 Content-Type: multipart/alternative; boundary=Apple-Mail-5--847791352 --Apple-Mail-5--847791352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as OSPF WG Co-chair, This draft was presented at the Homenet WG in Tai Pei and the OSPF WG in = Paris. If OSPFv3 is adopted as the Homenet routing protocol, = auto-configuration is required.=20 Please state whether or not you support its adoption as an OSPF WG = Document. Thanks, Acee =20 Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT > To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt >=20 > A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has = been successfully submitted by Acee Lindem and posted to the IETF = repository. >=20 > Filename: draft-acee-ospf-ospfv3-autoconfig > Revision: 02 > Title: OSPFv3 Auto-Configuration > Creation date: 2012-05-28 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be = self-configuring. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-5--847791352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: May 28, 2012 3:41:15 PM EDT
To: Acee Lindem <acee.lindem@ericsson.com><= br>
Subject: New Version = Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt

A = new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been = successfully submitted by Acee Lindem and posted to the IETF = repository.

Filename: = draft-acee-ospf-ospfv3-autoconfig
Revision: = 02
Title: = = OSPFv3 Auto-Configuration
Creation date: = 2012-05-28
WG ID: Individual Submission
Number = of pages: 14

Abstract:
  OSPFv3 is a candidate for = deployments in environments where auto-
  configuration is = a requirement.  One such environment is the IPv6
=   home network where users expect to simply plug in a router = and have
  it automatically use OSPFv3 for intra-domain = routing.  This document
  describes the necessary = mechanisms for OSPFv3 to be self-configuring.




The = IETF Secretariat

= --Apple-Mail-5--847791352-- --Apple-Mail-6--847791336 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyODIwMjQyMVowIwYJKoZI hvcNAQkEMRYEFFvdxzqIknG3BvUgF+h66Vi7QHBZMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgGaq4ebvhy2lycELh1C4Vlu3sYWECSFnr327ocYXTI8HmAbhSAsV6COOKI3QUHDu ouJa0o4T0emsY/p6FSQOJPpNqJFMssJA783MxWj7YLc/pxXo7utWIBt4aoWA2EEqtKV0OxpQ/+LU npoel1ZA6/nwQvmnY7rSB3vFrSSslpm5AAAAAAAA --Apple-Mail-6--847791336-- From tanmoy.kundu@huawei.com Tue May 29 03:57:22 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74A21F87C0 for ; Tue, 29 May 2012 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZMlroXCxyt1 for ; Tue, 29 May 2012 03:57:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4572421F87BE for ; Tue, 29 May 2012 03:57:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGQ12953; Tue, 29 May 2012 06:57:21 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 May 2012 03:54:56 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 May 2012 03:54:55 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP Server id 14.1.323.3; Tue, 29 May 2012 18:54:51 +0800 From: Tanmoy To: Date: Tue, 29 May 2012 16:24:50 +0530 Organization: Htipl Message-ID: <000001cd3d89$794ce9b0$6be6bd10$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD3DB7.930525B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac09iXh7V3sfCGSVQPmSz7J3wwMmpQ== Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Subject: [OSPF] Regarding authentication MIB elements for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 10:57:22 -0000 ------=_NextPart_000_0001_01CD3DB7.930525B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, According to RFC 5643 [Management Information Base for OSPFv3 ] in the section Authentication, its mentioned as below " 2.3. Authentication In OSPFv3, authentication has been removed from the protocol itself. MIB objects related to authentication are not carried forward from the OSPFv2 MIB module. " However, with the publication of RFC 6503 [Supporting Authentication Trailer for OSPFv3], the statement above is no longer true. A revision to the MIB is required now. I would like to suggest to update RFC 5643 to reflect the new MIB element of authentication for OSPFv3. Regards, - Tanmoy ------=_NextPart_000_0001_01CD3DB7.930525B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

According to RFC 5643 [Management Information Base for = OSPFv3 ] in the section Authentication, its mentioned as below =

“

2.3.  = Authentication

 

   In OSPFv3, authentication has been removed from the = protocol itself.

   MIB objects related to authentication are not carried = forward from

   the OSPFv2 MIB module. = “

 

 

However, with the publication of RFC = 6503 [Supporting Authentication Trailer for OSPFv3], the statement above = is no longer true. A revision to the MIB is required = now.

 

I would like to suggest to update = RFC 5643 to reflect the new MIB element of authentication for OSPFv3. =

 

Regards,

-   Tanmoy

 

------=_NextPart_000_0001_01CD3DB7.930525B0-- From alvaro.retana@hp.com Thu May 31 08:37:43 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CB911E8108 for ; Thu, 31 May 2012 08:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g64Um-vsDqt1 for ; Thu, 31 May 2012 08:37:41 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1953F11E8104 for ; Thu, 31 May 2012 08:37:41 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 6A1413829C; Thu, 31 May 2012 15:37:40 +0000 (UTC) Received: from G1W3636G.americas.hpqcorp.net (16.193.48.87) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 31 May 2012 15:34:17 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.130]) by G1W3636G.americas.hpqcorp.net ([16.193.48.87]) with mapi id 14.02.0283.003; Thu, 31 May 2012 15:34:02 +0000 From: "Retana, Alvaro" To: Acee Lindem , OSPF List Thread-Topic: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac09DyQnqTFj1+/PQ86sYeXCgFf1TwCMugDQ Date: Thu, 31 May 2012 15:34:01 +0000 Message-ID: References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> In-Reply-To: <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.192.88.244] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE701D7A3G2W2446americashp_" MIME-Version: 1.0 Cc: Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 15:37:43 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE701D7A3G2W2446americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! My reason for the suggestion was that requiring a special instance ID (even= if well known) takes away from the auto-* properties by requiring other ro= uters to behave in a special way. IOW, the use case of adding an auto-conf= iguration-capable router to an existing network would not be possible w/out= additional configuration and/or hacks. I obviously like option #2. :) IMHO, option #3 is not good because it still requires the auto-configuratio= n-capable router to be configured beforehand...which is an oxymoron! Thanks! Alvaro. From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Monday, May 28, 2012 4:19 PM To: OSPF List Cc: Jari Arkko; Retana, Alvaro Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfi= g-02.txt Speaking as a Draft Author: This version includes additions based on comments received at IETF 83. Sect= ion 5.1 clarifies the detection of a neighbor with a duplicate Router-ID to= exclude the case where multiple router interfaces are connected to the sam= e link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3= Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID resolu= tion. Additionally, we received a suggestion from Alvaro Retana to not use an res= erved OSPFv3 instance ID for auto-configured routers. Rather, allow OSPFv3 = auto-configured routers to use the default OSPFv3 instance ID and automatic= ally join an existing non-autoconfigured OSPFv3 routing domain. I see three= possible alternatives: 1. Reject the suggestion. The alternate OSPFv3 instance ID was added sp= ecifically to prevent this. 2. Adopt the suggestion and remove the reserved instance ID. The securi= ty considerations now recommend that implementation provide the capability = to configure a single key. 3. Add an applicability statement indicating that an implementation MAY= use the default OSPFv3 instance if the network where the implementation is= deployed requires incorporation into an existing OSPFv3 network. Please provide your thoughts on this issue. Thanks, Acee Begin forwarded message: From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.= txt A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been suc= cessfully submitted by Acee Lindem and posted to the IETF repository. Filename: draft-acee-ospf-ospfv3-autoconfig Revision: 02 Title: OSPFv3 Auto-Configuration Creation date: 2012-05-28 WG ID: Individual Submission Number of pages: 14 Abstract: OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. The IETF Secretariat --_000_C03AAF38AD209F4BB02BC0A34B774CE701D7A3G2W2446americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 <= /p>

My reason for the suggest= ion was that requiring a special instance ID (even if well known) takes awa= y from the auto-* properties by requiring other routers to behave in a special way.  IOW, the use case of adding an auto-conf= iguration-capable router to an existing network would not be possible w/out= additional configuration and/or hacks.

 <= /p>

I obviously like option #= 2. J

 <= /p>

IMHO, option #3 is not go= od because it still requires the auto-configuration-capable router to be co= nfigured beforehand…which is an oxymoron!

 <= /p>

Thanks!=

 <= /p>

Alvaro.=

 <= /p>

From: Acee Lin= dem [mailto:acee.lindem@ericsson.com]
Sent: Monday, May 28, 2012 4:19 PM
To: OSPF List
Cc: Jari Arkko; Retana, Alvaro
Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-au= toconfig-02.txt

 

Speaking as a Draft Author:

 

This version includes additions based on comments re= ceived at IETF 83. Section 5.1 clarifies the detection of a neighbor with a= duplicate Router-ID to exclude the case where multiple router interfaces a= re connected to the same link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3 Router-ID in t= he OSPFv3 routing domain prior to duplicate Router-ID resolution. 

 

Additionally, we received a suggestion from Alvaro R= etana to not use an reserved OSPFv3 instance ID for auto-configured routers= . Rather, allow OSPFv3 auto-configured routers to use the default OSPFv3 in= stance ID and automatically join an existing non-autoconfigured OSPFv3 routing domain. I see three possible al= ternatives:

 

    1. Reject the suggestion. The alternat= e OSPFv3 instance ID was added specifically to prevent this. 

    2. Adopt the suggestion and remove the= reserved instance ID. The security considerations now recommend that imple= mentation provide the capability to configure a single key. 

    3. Add an applicability statement indi= cating that an implementation MAY use the default OSPFv3 instance if the ne= twork where the implementation is deployed requires incorporation into an e= xisting OSPFv3 network. 

 

Please provide your thoughts on this issue. 

 

Thanks,

Acee

 

 

 

 

Begin forwarded message:



Date: May 28, 2012 3:41:15 PM EDT

To: Acee Lindem <acee.lindem@ericsson.com>

Subject: New Version Notification = for draft-acee-ospf-ospfv3-autoconfig-02.txt

 

A new version of I-D, draft-acee-ospf-ospfv3-autocon= fig-02.txt has been successfully submitted by Acee Lindem and posted to the= IETF repository.

Filename:      = ; draft-acee-ospf-ospfv3-autoconfig
Revision:      = ; 02
Title:      &n= bsp;       OSPFv3 Auto-Configuration Creation date:     =        2012-05-28
WG ID:      &n= bsp;            = ;  Individual Submission
Number of pages: 14

Abstract:
  OSPFv3 is a candidate for deployments in environments where aut= o-
  configuration is a requirement.  One such environment is t= he IPv6
  home network where users expect to simply plug in a router and = have
  it automatically use OSPFv3 for intra-domain routing.  Thi= s document
  describes the necessary mechanisms for OSPFv3 to be self-config= uring.




The IETF Secretariat

 

--_000_C03AAF38AD209F4BB02BC0A34B774CE701D7A3G2W2446americashp_-- From acee.lindem@ericsson.com Thu May 31 08:43:57 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82311E811C for ; Thu, 31 May 2012 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rydYcrEVbdbU for ; Thu, 31 May 2012 08:43:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3525A11E8119 for ; Thu, 31 May 2012 08:43:54 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4VFhomh004102; Thu, 31 May 2012 10:43:53 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 May 2012 11:43:47 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Thu, 31 May 2012 11:43:44 -0400 Thread-Topic: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac0/RCqU61zFhtkwRZmaLSNweOaP3A== Message-ID: <4E55EFFC-AC9F-4CAD-A959-658A37D9DD23@ericsson.com> References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List , Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 15:43:57 -0000 On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote: Hi! My reason for the suggestion was that requiring a special instance ID (even= if well known) takes away from the auto-* properties by requiring other ro= uters to behave in a special way. IOW, the use case of adding an auto-conf= iguration-capable router to an existing network would not be possible w/out= additional configuration and/or hacks. I obviously like option #2. :) IMHO, option #3 is not good because it still requires the auto-configuratio= n-capable router to be configured beforehand=85which is an oxymoron! This was not the intent of #3 - it was meant to allow an implementation to = decide dependent on the targeted deployments. Even without the reserved ins= tance ID, other parameters (area, hello, dead, etc) in the existing network= would need to use the auto-configured values. Thanks, Acee Thanks! Alvaro. From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Monday, May 28, 2012 4:19 PM To: OSPF List Cc: Jari Arkko; Retana, Alvaro Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfi= g-02.txt Speaking as a Draft Author: This version includes additions based on comments received at IETF 83. Sect= ion 5.1 clarifies the detection of a neighbor with a duplicate Router-ID to= exclude the case where multiple router interfaces are connected to the sam= e link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3= Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID resolu= tion. Additionally, we received a suggestion from Alvaro Retana to not use an res= erved OSPFv3 instance ID for auto-configured routers. Rather, allow OSPFv3 = auto-configured routers to use the default OSPFv3 instance ID and automatic= ally join an existing non-autoconfigured OSPFv3 routing domain. I see three= possible alternatives: 1. Reject the suggestion. The alternate OSPFv3 instance ID was added sp= ecifically to prevent this. 2. Adopt the suggestion and remove the reserved instance ID. The securi= ty considerations now recommend that implementation provide the capability = to configure a single key. 3. Add an applicability statement indicating that an implementation MAY= use the default OSPFv3 instance if the network where the implementation is= deployed requires incorporation into an existing OSPFv3 network. Please provide your thoughts on this issue. Thanks, Acee Begin forwarded message: From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.= txt A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been suc= cessfully submitted by Acee Lindem and posted to the IETF repository. Filename: draft-acee-ospf-ospfv3-autoconfig Revision: 02 Title: OSPFv3 Auto-Configuration Creation date: 2012-05-28 WG ID: Individual Submission Number of pages: 14 Abstract: OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. The IETF Secretariat From alvaro.retana@hp.com Thu May 31 13:14:28 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA121F8631 for ; Thu, 31 May 2012 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMg3ove0UES5 for ; Thu, 31 May 2012 13:14:25 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id 03DC821F8627 for ; Thu, 31 May 2012 13:14:24 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 4F62E3851F; Thu, 31 May 2012 20:14:24 +0000 (UTC) Received: from G1W3637G.americas.hpqcorp.net (16.193.48.88) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 31 May 2012 20:13:49 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.130]) by G1W3637G.americas.hpqcorp.net ([16.193.48.88]) with mapi id 14.02.0283.003; Thu, 31 May 2012 20:13:48 +0000 From: "Retana, Alvaro" To: Acee Lindem Thread-Topic: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac09DyQnqTFj1+/PQ86sYeXCgFf1TwCMugDQAACHLwAACRIzIA== Date: Thu, 31 May 2012 20:13:47 +0000 Message-ID: References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> <4E55EFFC-AC9F-4CAD-A959-658A37D9DD23@ericsson.com> In-Reply-To: <4E55EFFC-AC9F-4CAD-A959-658A37D9DD23@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.192.88.244] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE701E9B2G2W2446americashp_" MIME-Version: 1.0 Cc: OSPF List , Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 20:14:28 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE701E9B2G2W2446americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acee: OK...but deciding on what to do on a specific deployment without manually c= onfiguring the router is not trivial. As far as other parameters, the draft seems to specify fixed values which a= re not specific to a deployment. BTW, the draft reads "OSPFv3 interfaces MUST auto-configure the default Hel= loInterval and RouterDeadInterval as specified in [OSPFV3]."..but rfc5340 = doesn't actually specify a default value, just provides examples: HelloInterval The length of time, in seconds, between Hello packets that the router sends on the interface. This value is advertised in the router's Hello packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected. However, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds. RouterDeadInterval After ceasing to hear a router's Hello packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (e.g., 4). This value again MUST be the same for all routers attached to a common link. Alvaro. From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Thursday, May 31, 2012 11:44 AM To: Retana, Alvaro Cc: OSPF List; Jari Arkko Subject: Re: New Version Notification for draft-acee-ospf-ospfv3-autoconfig= -02.txt On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote: Hi! My reason for the suggestion was that requiring a special instance ID (even= if well known) takes away from the auto-* properties by requiring other ro= uters to behave in a special way. IOW, the use case of adding an auto-conf= iguration-capable router to an existing network would not be possible w/out= additional configuration and/or hacks. I obviously like option #2. :) IMHO, option #3 is not good because it still requires the auto-configuratio= n-capable router to be configured beforehand...which is an oxymoron! This was not the intent of #3 - it was meant to allow an implementation to = decide dependent on the targeted deployments. Even without the reserved ins= tance ID, other parameters (area, hello, dead, etc) in the existing network= would need to use the auto-configured values. Thanks, Acee Thanks! Alvaro. From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Monday, May 28, 2012 4:19 PM To: OSPF List Cc: Jari Arkko; Retana, Alvaro Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfi= g-02.txt Speaking as a Draft Author: This version includes additions based on comments received at IETF 83. Sect= ion 5.1 clarifies the detection of a neighbor with a duplicate Router-ID to= exclude the case where multiple router interfaces are connected to the sam= e link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3= Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID resolu= tion. Additionally, we received a suggestion from Alvaro Retana to not use an res= erved OSPFv3 instance ID for auto-configured routers. Rather, allow OSPFv3 = auto-configured routers to use the default OSPFv3 instance ID and automatic= ally join an existing non-autoconfigured OSPFv3 routing domain. I see three= possible alternatives: 1. Reject the suggestion. The alternate OSPFv3 instance ID was added sp= ecifically to prevent this. 2. Adopt the suggestion and remove the reserved instance ID. The securi= ty considerations now recommend that implementation provide the capability = to configure a single key. 3. Add an applicability statement indicating that an implementation MAY= use the default OSPFv3 instance if the network where the implementation is= deployed requires incorporation into an existing OSPFv3 network. Please provide your thoughts on this issue. Thanks, Acee Begin forwarded message: From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.= txt A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been suc= cessfully submitted by Acee Lindem and posted to the IETF repository. Filename: draft-acee-ospf-ospfv3-autoconfig Revision: 02 Title: OSPFv3 Auto-Configuration Creation date: 2012-05-28 WG ID: Individual Submission Number of pages: 14 Abstract: OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. The IETF Secretariat --_000_C03AAF38AD209F4BB02BC0A34B774CE701E9B2G2W2446americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 <= /p>

OK…but deciding on = what to do on a specific deployment without manually configuring the router= is not trivial.

 <= /p>

As far as other parameter= s, the draft seems to specify fixed values which are not specific to a depl= oyment.

 <= /p> 

BTW, the draft reads “OSPFv3 i=
nterfaces MUST auto-configure the default HelloInterval and RouterDeadInter=
val as specified in [OSPFV3=
].”..but rfc5340 doesn’t actuall=
y specify a default value, just provides examples:

 <= /p>

   HelloInterval

      The length of time, in seco= nds, between Hello packets that the

      router sends on the interfa= ce.  This value is advertised in the

      router's Hello packets.&nbs= p; It MUST be the same for all routers

      attached to a common link.&= nbsp; The smaller the HelloInterval, the

      faster topological changes = will be detected.  However, more OSPF

      routing protocol traffic wi= ll ensue.  Sample value for a X.25 PDN:

      30 seconds.  Sample va= lue for a local area network (LAN): 10

      seconds.<= /p>

 

   RouterDeadInterval

      After ceasing to hear a rou= ter's Hello packets, the number of

      seconds before its neighbor= s declare the router down.  This is

      also advertised in the rout= er's Hello packets in their

      RouterDeadInterval field.&n= bsp; This should be some multiple of the

      HelloInterval (e.g., 4).&nb= sp; This value again MUST be the same for

      all routers attached to a c= ommon link.

 <= /p>

Alvaro.=

 <= /p>

From: Acee Lin= dem [mailto:acee.lindem@ericsson.com]
Sent: Thursday, May 31, 2012 11:44 AM
To: Retana, Alvaro
Cc: OSPF List; Jari Arkko
Subject: Re: New Version Notification for draft-acee-ospf-ospfv3-aut= oconfig-02.txt

 

 

On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote:<= o:p>



Hi!

 <= /p>

My reason for the suggest= ion was that requiring a special instance ID (even if well known) takes awa= y from the auto-* properties by requiring other routers to behave in a special way.  IOW, the use case of adding an auto-conf= iguration-capable router to an existing network would not be possible w/out= additional configuration and/or hacks.

 <= /p>

I obviously like option #= 2. J

 <= /p>

IMHO, option #3 is not go= od because it still requires the auto-configuration-capable router to be co= nfigured beforehand…which is an oxymoron!

 

This was not the intent of #3 - it was meant to allo= w an implementation to decide dependent on the targeted deployments. Even w= ithout the reserved instance ID, other parameters (area, hello, dead, etc) = in the existing network would need to use the auto-configured values. 

 

Thanks,

Acee 

 



 <= /p>

Thanks!=

 <= /p>

Alvaro.=

 <= /p>

From: Acee Lindem [mailto:acee.lindem@ericsson.com] 
Sent: Monday, May = 28, 2012 4:19 PM
To: OSPF List
Cc: Jari Arkko; Re= tana, Alvaro
Subject: Fwd: New = Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt

 

Speaking as a Draft Author:

 

This version includes additions based on comments re= ceived at IETF 83. Section 5.1 clarifies the detection of a neighbor with a= duplicate Router-ID to exclude the case where multiple router interfaces a= re connected to the same link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3 Router-ID in t= he OSPFv3 routing domain prior to duplicate Router-ID resolution. 

 

Additionally, we received a suggestion from Alvaro R= etana to not use an reserved OSPFv3 instance ID for auto-configured routers= . Rather, allow OSPFv3 auto-configured routers to use the default OSPFv3 in= stance ID and automatically join an existing non-autoconfigured OSPFv3 routing domain. I see three possible al= ternatives:

 

    1. Reject the suggestion. The alternat= e OSPFv3 instance ID was added specifically to prevent this. 

    2. Adopt the suggestion and remove the= reserved instance ID. The security considerations now recommend that imple= mentation provide the capability to configure a single key. 

    3. Add an applicability statement indi= cating that an implementation MAY use the default OSPFv3 instance if the ne= twork where the implementation is deployed requires incorporation into an e= xisting OSPFv3 network. 

 

Please provide your thoughts on this issue. 

 

Thanks,

Acee

 

 

 

 

Begin forwarded message:




Date: May 28, 2012 3:41:15 PM EDT=

Subject: New Version Notification = for draft-acee-ospf-ospfv3-autoconfig-02.txt

 

A new version of I-D, draft-acee-ospf-ospfv3-autocon= fig-02.txt has been successfully submitted by Acee Lindem and posted to the= IETF repository.

Filename:      = ; draft-acee-ospf-= ospfv3-autoconfig
Revision:      = ; 02
Title:      &n= bsp;       OSPFv3 Auto-Configuration
Creation date:     =        2012-05-28
WG ID:      &n= bsp;            = ;  Individual= Submission
Number of pages: 14

Abstract:
  OSPFv3 is a candidate for deployments in environments where aut= o-
  configuration is a requirement.  One such environment is t= he IPv6
  home network where users expect to simply plug in a router and = have
  it automatically use OSPFv3 for intra-domain routing.  Thi= s document
  describes the necessary mechanisms for OSPFv3 to be self-config= uring.




The IETF Secretariat

 

 

--_000_C03AAF38AD209F4BB02BC0A34B774CE701E9B2G2W2446americashp_-- From acee.lindem@ericsson.com Thu May 31 14:22:07 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB121F8638 for ; Thu, 31 May 2012 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYfiLXGMjfkD for ; Thu, 31 May 2012 14:22:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 075B221F8621 for ; Thu, 31 May 2012 14:22:03 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4VLM109018047; Thu, 31 May 2012 16:22:03 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 31 May 2012 17:21:54 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Thu, 31 May 2012 17:21:51 -0400 Thread-Topic: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac0/c2bB9mLJgssARHWyXUkJ3VX/WQ== Message-ID: References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> <4E55EFFC-AC9F-4CAD-A959-658A37D9DD23@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-9--585141431"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: OSPF List , Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 21:22:07 -0000 --Apple-Mail-9--585141431 Content-Type: multipart/alternative; boundary=Apple-Mail-8--585141457 --Apple-Mail-8--585141457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2012, at 4:13 PM, Retana, Alvaro wrote: > Acee: > =20 > OK=85but deciding on what to do on a specific deployment without = manually configuring the router is not trivial. > =20 > As far as other parameters, the draft seems to specify fixed values = which are not specific to a deployment. That's why interaction between configured and auto-configured routers = doesn't seem like a likely deployment and using a reserved instance ID = seems reasonable. =20 Acee=20 > =20 > BTW, the draft reads =93OSPFv3 interfaces MUST auto-configure the = default HelloInterval and RouterDeadInterval as specified in = [OSPFV3].=94..but rfc5340 doesn=92t actually specify a default value, = just provides examples: > =20 > HelloInterval > The length of time, in seconds, between Hello packets that the > router sends on the interface. This value is advertised in the > router's Hello packets. It MUST be the same for all routers > attached to a common link. The smaller the HelloInterval, the > faster topological changes will be detected. However, more OSPF > routing protocol traffic will ensue. Sample value for a X.25 = PDN: > 30 seconds. Sample value for a local area network (LAN): 10 > seconds. > =20 > RouterDeadInterval > After ceasing to hear a router's Hello packets, the number of > seconds before its neighbors declare the router down. This is > also advertised in the router's Hello packets in their > RouterDeadInterval field. This should be some multiple of the > HelloInterval (e.g., 4). This value again MUST be the same for > all routers attached to a common link. > =20 > Alvaro. > =20 > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Thursday, May 31, 2012 11:44 AM > To: Retana, Alvaro > Cc: OSPF List; Jari Arkko > Subject: Re: New Version Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt > =20 > =20 > On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote: >=20 >=20 > Hi! > =20 > My reason for the suggestion was that requiring a special instance ID = (even if well known) takes away from the auto-* properties by requiring = other routers to behave in a special way. IOW, the use case of adding = an auto-configuration-capable router to an existing network would not be = possible w/out additional configuration and/or hacks. > =20 > I obviously like option #2. J > =20 > IMHO, option #3 is not good because it still requires the = auto-configuration-capable router to be configured beforehand=85which is = an oxymoron! > =20 > This was not the intent of #3 - it was meant to allow an = implementation to decide dependent on the targeted deployments. Even = without the reserved instance ID, other parameters (area, hello, dead, = etc) in the existing network would need to use the auto-configured = values.=20 > =20 > Thanks, > Acee=20 > =20 >=20 >=20 > =20 > Thanks! > =20 > Alvaro. > =20 > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Monday, May 28, 2012 4:19 PM > To: OSPF List > Cc: Jari Arkko; Retana, Alvaro > Subject: Fwd: New Version Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt > =20 > Speaking as a Draft Author: > =20 > This version includes additions based on comments received at IETF 83. = Section 5.1 clarifies the detection of a neighbor with a duplicate = Router-ID to exclude the case where multiple router interfaces are = connected to the same link. Section 5.4 was added to mitigate the = effects of a duplicate OSPFv3 Router-ID in the OSPFv3 routing domain = prior to duplicate Router-ID resolution.=20 > =20 > Additionally, we received a suggestion from Alvaro Retana to not use = an reserved OSPFv3 instance ID for auto-configured routers. Rather, = allow OSPFv3 auto-configured routers to use the default OSPFv3 instance = ID and automatically join an existing non-autoconfigured OSPFv3 routing = domain. I see three possible alternatives: > =20 > 1. Reject the suggestion. The alternate OSPFv3 instance ID was = added specifically to prevent this.=20 > 2. Adopt the suggestion and remove the reserved instance ID. The = security considerations now recommend that implementation provide the = capability to configure a single key.=20 > 3. Add an applicability statement indicating that an = implementation MAY use the default OSPFv3 instance if the network where = the implementation is deployed requires incorporation into an existing = OSPFv3 network.=20 > =20 > Please provide your thoughts on this issue.=20 > =20 > Thanks, > Acee > =20 > =20 > =20 > =20 > Begin forwarded message: >=20 >=20 >=20 > From: "internet-drafts@ietf.org" > Date: May 28, 2012 3:41:15 PM EDT > To: Acee Lindem > Cc: "jari.arkko@piuha.net" > Subject: New Version Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt > =20 > A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has = been successfully submitted by Acee Lindem and posted to the IETF = repository. >=20 > Filename: draft-acee-ospf-ospfv3-autoconfig > Revision: 02 > Title: OSPFv3 Auto-Configuration > Creation date: 2012-05-28 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be = self-configuring. >=20 >=20 >=20 >=20 > The IETF Secretariat > =20 > =20 --Apple-Mail-8--585141457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 31, 2012, at 4:13 PM, Retana, = Alvaro wrote:

As = far as other parameters, the draft seems to specify fixed values which = are not specific to a = deployment.

That's why interaction between configured and auto-configured routers = doesn't seem like a likely deployment and using a reserved instance ID = seems reasonable. =  

Acee 



BTW, the = draft reads =93OSPFv3 interfaces MUST auto-configure the default = HelloInterval and RouterDeadInterval as specified in [OSPFV3].   = HelloInterval
      The = length of time, in seconds, between Hello packets that = the
      router = sends on the interface.  This value is advertised in = the
      router's = Hello packets.  It MUST be the same for all = routers
      = attached to a common link.  The smaller the HelloInterval, = the
      faster = topological changes will be detected.  However, more = OSPF
      routing = protocol traffic will ensue.  Sample value for a X.25 = PDN:
      30 = seconds.  Sample value for a local area network (LAN): = 10
      = seconds.
 
   RouterDeadInterval
      After ceasing to hear a router's = Hello packets, the number of
      seconds before its neighbors = declare the router down.  This is
      also advertised in the router's = Hello packets in their
      HelloInterval (e.g., 4).  = This value again MUST be the same for
      all routers attached to a common = link.
 Acee = Lindem [mailto:acee.lindem@ericsson.com] 
Sent: Thursday, May 31, 2012 = 11:44 AM
To: Retana, = Alvaro
Cc: OSPF List; Jari = Arkko
Subject: Re: New Version = Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt
 
On May 31, 2012, at 11:34 = AM, Retana, Alvaro wrote:
My reason for the suggestion was that requiring a = special instance ID (even if well known) takes away from the auto-* = properties by requiring other routers to behave in a special way.  = IOW, the use case of adding an auto-configuration-capable router to an = existing network would not be possible w/out additional configuration = and/or hacks.
 
I obviously like option #2. J
 
IMHO, option #3 is not good = because it still requires the auto-configuration-capable router to be = configured beforehand=85which is an = oxymoron!
 
This was not the intent of #3 - it was meant to allow = an implementation to decide dependent on the targeted deployments. Even = without the reserved instance ID, other parameters (area, hello, dead, = etc) in the existing network would need to use the auto-configured = values. 
Thanks!
Alvaro.
Acee Lindem [mailto:acee.lindem@ericsson.com] 
Sent: Monday, May 28, 2012 4:19 = PM
To: OSPF = List
Cc: Jari = Arkko; Retana, Alvaro
Subject: Fwd: New Version = Notification for = draft-acee-ospf-ospfv3-autoconfig-02.txt
 
Speaking as a Draft = Author:
This version includes = additions based on comments received at IETF 83. Section 5.1 clarifies = the detection of a neighbor with a duplicate Router-ID to exclude the = case where multiple router interfaces are connected to the same link. = Section 5.4 was added to mitigate the effects of a duplicate OSPFv3 = Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID = resolution. 
 
Additionally, we received a suggestion from Alvaro = Retana to not use an reserved OSPFv3 instance ID for auto-configured = routers. Rather, allow OSPFv3 auto-configured routers to use the default = OSPFv3 instance ID and automatically join an existing non-autoconfigured = OSPFv3 routing domain. I see three possible = alternatives:
 
    1. Reject the suggestion. The alternate = OSPFv3 instance ID was added specifically to prevent = this. 
    2. Adopt the suggestion and remove the = reserved instance ID. The security considerations now recommend that = implementation provide the capability to configure a single = key. 
    = 3. Add an applicability statement indicating that an implementation MAY = use the default OSPFv3 instance if the network where the implementation = is deployed requires incorporation into an existing OSPFv3 = network. 
 
Please provide your thoughts on this = issue. 
 
Thanks,
Acee
 
 
 
A new version of I-D, = draft-acee-ospf-ospfv3-autoconfig-02.txt has been successfully submitted = by Acee Lindem and posted to the IETF repository.

Filename:       draft-acee-ospf-ospfv3-autoco= nfig
Revision:       02
Title:        &= nbsp;     OSPFv3 = Auto-Configuration
Creation date:        &= nbsp;   2012-05-28
WG ID:        &= nbsp;            Individual = Submission
Number of pages: 14

Abstract:
  OSPFv3 = is a candidate for deployments in environments where = auto-
  configuration is a requirement.  One such = environment is the IPv6
  home network where users expect = to simply plug in a router and have
  it automatically use = OSPFv3 for intra-domain routing.  This = document
  describes the necessary mechanisms for OSPFv3 to = be self-configuring.




The IETF = Secretariat
X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEE321F864F for ; Thu, 31 May 2012 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vodCTHKMZEBH for ; Thu, 31 May 2012 14:35:51 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id 14ED421F864C for ; Thu, 31 May 2012 14:35:51 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id EF3BF2ACAD5; Thu, 31 May 2012 21:35:49 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 033qeEVjU5120M01; Thu, 31 May 2012 21:35:46 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap01.cms.usa.net [165.212.11.1] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID058qeEVjv2318X01; Thu, 31 May 2012 21:35:47 -0000 X-USANET-Source: 165.212.11.1 IN michael_barnes@usa.net imap01.cms.usa.net X-USANET-MsgId: XID058qeEVjv2318X01 Received: from web02.cms.usa.net [165.212.8.202] by imap01.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 872qeEVjU2736M21; Thu, 31 May 2012 21:35:46 -0000 X-USANET-Auth: 165.212.8.202 AUTO michael_barnes@usa.net web02.cms.usa.net Received: from 128.107.239.233 [128.107.239.233] by web02.cms.usa.net (USANET web-mailer C8.MAIN.3.83I); Thu, 31 May 2012 21:35:46 -0000 Date: Thu, 31 May 2012 14:35:46 -0700 From: "Michael Barnes" To: Acee Lindem , "Retana, Alvaro" X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <310qeEVIU5616S02.1338500146@web02.cms.usa.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID872qeEVjU2736X21 Cc: OSPF List , Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 21:35:52 -0000 Hi Acee, If you do use a reserved instance ID, then there should be one per addres= s family in accordance with RFC5838. This is needed to allow for the fact t= hat we use a different instances for each AF. Regards, Michael ------ Original Message ------ Received: Thu, 31 May 2012 02:22:21 PM PDT From: Acee Lindem To: "Retana, Alvaro" Cc: OSPF List ,= Jari Arkko Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt > = > On May 31, 2012, at 4:13 PM, Retana, Alvaro wrote: > = > > Acee: > > = > > OK=85but deciding on what to do on a specific deployment without manu= ally configuring the router is not trivial. > > = > > As far as other parameters, the draft seems to specify fixed values w= hich are not specific to a deployment. > = > That's why interaction between configured and auto-configured routers doesn't seem like a likely deployment and using a reserved instance ID se= ems reasonable. = > = > Acee = > = > = > = > > = > > BTW, the draft reads =93OSPFv3 interfaces MUST auto-configure the def= ault HelloInterval and RouterDeadInterval as specified in [OSPFV3].=94..but rf= c5340 doesn=92t actually specify a default value, just provides examples: > > = > > HelloInterval > > The length of time, in seconds, between Hello packets that the > > router sends on the interface. This value is advertised in the= > > router's Hello packets. It MUST be the same for all routers > > attached to a common link. The smaller the HelloInterval, the > > faster topological changes will be detected. However, more OSP= F > > routing protocol traffic will ensue. Sample value for a X.25 P= DN: > > 30 seconds. Sample value for a local area network (LAN): 10 > > seconds. > > = > > RouterDeadInterval > > After ceasing to hear a router's Hello packets, the number of > > seconds before its neighbors declare the router down. This is > > also advertised in the router's Hello packets in their > > RouterDeadInterval field. This should be some multiple of the > > HelloInterval (e.g., 4). This value again MUST be the same for= > > all routers attached to a common link. > > = > > Alvaro. > > = > > From: Acee Lindem [mailto:acee.lindem@ericsson.com] = > > Sent: Thursday, May 31, 2012 11:44 AM > > To: Retana, Alvaro > > Cc: OSPF List; Jari Arkko > > Subject: Re: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt > > = > > = > > On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote: > > = > > = > > Hi! > > = > > My reason for the suggestion was that requiring a special instance ID= (even if well known) takes away from the auto-* properties by requiring o= ther routers to behave in a special way. IOW, the use case of adding an auto-configuration-capable router to an existing network would not be pos= sible w/out additional configuration and/or hacks. > > = > > I obviously like option #2. J > > = > > IMHO, option #3 is not good because it still requires the auto-configuration-capable router to be configured beforehand=85which is = an oxymoron! > > = > > This was not the intent of #3 - it was meant to allow an implementati= on to decide dependent on the targeted deployments. Even without the reserved instance ID, other parameters (area, hello, dead, etc) in the existing ne= twork would need to use the auto-configured values. = > > = > > Thanks, > > Acee = > > = > > = > > = > > = > > Thanks! > > = > > Alvaro. > > = > > From: Acee Lindem [mailto:acee.lindem@ericsson.com] = > > Sent: Monday, May 28, 2012 4:19 PM > > To: OSPF List > > Cc: Jari Arkko; Retana, Alvaro > > Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt > > = > > Speaking as a Draft Author: > > = > > This version includes additions based on comments received at IETF 83= =2E Section 5.1 clarifies the detection of a neighbor with a duplicate Router= -ID to exclude the case where multiple router interfaces are connected to the= same link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3= Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID resolution. = > > = > > Additionally, we received a suggestion from Alvaro Retana to not use = an reserved OSPFv3 instance ID for auto-configured routers. Rather, allow OS= PFv3 auto-configured routers to use the default OSPFv3 instance ID and automatically join an existing non-autoconfigured OSPFv3 routing domain. = I see three possible alternatives: > > = > > 1. Reject the suggestion. The alternate OSPFv3 instance ID was ad= ded specifically to prevent this. = > > 2. Adopt the suggestion and remove the reserved instance ID. The security considerations now recommend that implementation provide the capability to configure a single key. = > > 3. Add an applicability statement indicating that an implementati= on MAY use the default OSPFv3 instance if the network where the implementati= on is deployed requires incorporation into an existing OSPFv3 network. = > > = > > Please provide your thoughts on this issue. = > > = > > Thanks, > > Acee > > = > > = > > = > > = > > Begin forwarded message: > > = > > = > > = > > From: "internet-drafts@ietf.org" > > Date: May 28, 2012 3:41:15 PM EDT > > To: Acee Lindem > > Cc: "jari.arkko@piuha.net" > > Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt > > = > > A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has be= en successfully submitted by Acee Lindem and posted to the IETF repository. > > = > > Filename: draft-acee-ospf-ospfv3-autoconfig > > Revision: 02 > > Title: OSPFv3 Auto-Configuration > > Creation date: 2012-05-28 > > WG ID: Individual Submission > > Number of pages: 14 > > = > > Abstract: > > OSPFv3 is a candidate for deployments in environments where auto- > > configuration is a requirement. One such environment is the IPv6 > > home network where users expect to simply plug in a router and have= > > it automatically use OSPFv3 for intra-domain routing. This documen= t > > describes the necessary mechanisms for OSPFv3 to be self-configurin= g. > > = > > = > > = > > = > > The IETF Secretariat > > = > > = > = > = > --------------------------------------------- = > Attachment:=A0smime.p7s > MIME Type:=A0application/pkcs7-signature > --------------------------------------------- From russw@riw.us Thu May 31 16:23:49 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF2521F8594 for ; Thu, 31 May 2012 16:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZXK8w-RuDvZ for ; Thu, 31 May 2012 16:23:48 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id D877C21F84DE for ; Thu, 31 May 2012 16:23:48 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaEia-00088v-MV for ospf@ietf.org; Thu, 31 May 2012 16:23:48 -0700 Message-ID: <4FC7FD85.7000606@riw.us> Date: Thu, 31 May 2012 19:23:49 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ospf@ietf.org References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com> <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 31 May 2012 23:23:49 -0000 > 3. Add an applicability statement indicating that an implementation > MAY use the default OSPFv3 instance if the network where the > implementation is deployed requires incorporation into an existing > OSPFv3 network. I think this is the best option --the default should be to join an existing domain, so the default behavior "just works," but the option should be there to do otherwise if the network administrator has a specific reason to provide an alternate or reserved instance ID. Russ -- <>< riwhite@verisign.com russw@riw.us