From thomas.r.henderson@boeing.com Sat Jun 1 15:29:05 2013 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 130FF21F992A for ; Sat, 1 Jun 2013 15:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lH5FNbxR6Fg9 for ; Sat, 1 Jun 2013 15:29:00 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4D96021F8DDD for ; Sat, 1 Jun 2013 15:28:58 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r51MSvRM017751 for ; Sat, 1 Jun 2013 17:28:58 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r51MSucd017748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 1 Jun 2013 17:28:57 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Sat, 1 Jun 2013 15:28:56 -0700 From: "Henderson, Thomas R" To: "'Acee Lindem'" , "'rich.ogier@earthlink.net'" Date: Sat, 1 Jun 2013 15:28:56 -0700 Thread-Topic: [OSPF] OSPF WG Last Call: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt (Corrected) Thread-Index: AQHOM8MykpZnRxb3wUyTsZ0rU2D/MZkhxU8Q Message-ID: <758141CC3D829043A8C3164DD3D593EA2EA6C32458@XCH-NW-16V.nw.nos.boeing.com> References: <94A203EA12AECE4BA92D42DBFFE0AE4711038C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471103F0@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE471103F0@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: OSPF List Subject: Re: [OSPF] OSPF WG Last Call: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt (Corrected) 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: Sat, 01 Jun 2013 22:29:05 -0000 > All,=A0 > > I'd like to start a 3 week WG last call on the subject document. The last= call will end at=20 > 12:00 AM PDT on April 29th, 2012. Please review the document and send any= comments to the=20 > list prior to that time. Here is a URL for your convenience:=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Acee and Richard, I realize that WGLC has passed on this draft, but I recently reviewed the l= atest (-02) version of this draft and had a few comments: - I did not perceive any technical problems; however, I have not implemente= d or tested it - the capability supports an important use case for OSPF MDR, and I think t= he section 2 guidance will be helpful to experimenters - I think the draft could be (optionally) improved for readers with an addi= tional motivating statement, along the lines of what is stated in RFC 6845.= Perhaps something at the bottom of page 1 like: "The rationale for using = this interface type for single-hop broadcast networks, instead of a broadca= st interface type, is to represent the underlying network in a point-to-mul= tipoint manner, to allow finer granularity of neighbor cost settings. In t= his sense, this document shows how the OSPF MDR interface type can be confi= gured to provide the same kind of interface as specified in [RFC6845]."=20 Overall, it seems to be ready to publish. - Tom From ogier@earthlink.net Mon Jun 3 15:07:15 2013 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 AF1B421F861F for ; Mon, 3 Jun 2013 15:07:15 -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 nFPMT-XQkqF2 for ; Mon, 3 Jun 2013 15:07:00 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2258F11E80F4 for ; Mon, 3 Jun 2013 15:02:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kStFFcjJOelzND2xM1S2vvv20hQpBDJx3Swxrf23MQveRehil510ja0hjjYj8fOW; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [71.128.200.145] (helo=[192.168.0.3]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ujcpf-0005kf-2B; Mon, 03 Jun 2013 18:02:28 -0400 Message-ID: <51AD1275.30406@earthlink.net> Date: Mon, 03 Jun 2013 15:02:29 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "" References: <94A203EA12AECE4BA92D42DBFFE0AE4711038C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471103F0@eusaamb101.ericsson.se> <758141CC3D829043A8C3164DD3D593EA2EA6C32458@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2EA6C32458@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478e549f294dc8ae39d43997510a9f083d1478b19569c7702ea350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.128.200.145 Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF WG Last Call: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt (Corrected) 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, 03 Jun 2013 22:07:15 -0000 Tom, Thanks for your review and comments. I added a motivating paragraph as you suggested, and submitted the revised draft: http://www.ietf.org/id/draft-ietf-ospf-manet-single-hop-mdr-03.txt Richard On 6/1/2013 3:28 PM, Henderson, Thomas R wrote: >> All, >> >> I'd like to start a 3 week WG last call on the subject document. The last call will end at >> 12:00 AM PDT on April 29th, 2012. Please review the document and send any comments to the >> list prior to that time. Here is a URL for your convenience: >> >> https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ > Acee and Richard, > I realize that WGLC has passed on this draft, but I recently reviewed the latest (-02) version of this draft and had a few comments: > > - I did not perceive any technical problems; however, I have not implemented or tested it > - the capability supports an important use case for OSPF MDR, and I think the section 2 guidance will be helpful to experimenters > - I think the draft could be (optionally) improved for readers with an additional motivating statement, along the lines of what is stated in RFC 6845. Perhaps something at the bottom of page 1 like: "The rationale for using this interface type for single-hop broadcast networks, instead of a broadcast interface type, is to represent the underlying network in a point-to-multipoint manner, to allow finer granularity of neighbor cost settings. In this sense, this document shows how the OSPF MDR interface type can be configured to provide the same kind of interface as specified in [RFC6845]." > > Overall, it seems to be ready to publish. > > - Tom > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2242 / Virus Database: 3184/5876 - Release Date: 06/02/13 > > > From acee.lindem@ericsson.com Tue Jun 4 07:15:01 2013 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 C383B21F9C05; Tue, 4 Jun 2013 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] 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 m4QhAQ3BG96X; Tue, 4 Jun 2013 07:14:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7630B21F9AFB; Tue, 4 Jun 2013 05:37:10 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-48-51addf752121 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.2C.05617.57FDDA15; Tue, 4 Jun 2013 14:37:09 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 08:37:09 -0400 From: Acee Lindem To: Stewart Bryant , Adrian Farrel Thread-Topic: Publication Request for "Use of OSPF-MDR in Single-Hop Broadcast Networks" Thread-Index: AQHOYSA6Tb2BDEZaLkaBXD5XOOk6OA== Date: Tue, 4 Jun 2013 12:37:08 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715B435@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyuXRPoG7p/bWBBvOWG1v86LnBbLG0t4XF 4tWzfjaLlnv32C3OPZ3D6MDqMeX3RlaPVV8mMHssWfKTyWPF5pWMASxRXDYpqTmZZalF+nYJ XBlfl75nLOjMqehZ/JS9gbEho4uRk0NCwERiz/T/bBC2mMSFe+vBbCGBo4wS216zdDFyAdnL GCVWTjzFCJJgE9CReP7oHzOILSLgI7Fy+lt2EJtZoEji3OnHYHFhgTCJHwu3QNVES8xZ9gTK 1pNYsmwNmM0ioCJxYsIbsGW8At4SXT0gyzg5GIGO+H5qDRPETHGJW0/mM0EcJyLx8OJpqENF JV4+/scKYStLLHmynwWiPlPizM2bUDMFJU7OfMIygVF4FpJRs5CUzUJSBhHPlzj3rRmqRkdi we5PbBC2tsSyha+ZYewzBx5D1VhL7L73BIuaAInZbffYIWwniT+zVzHOAoYjs8AZRomnW/+x wzQv6NwAZStKTOl+yL6AkW8VI0dpcWpZbrqR4SZGYAI4JsHmuINxwSfLQ4zSHCxK4rw6vIsD hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCadTQ2Z304d892wv9D7NtnNvN09C8UjRW3+qr8 NKeK4cjzMqbXAY887TSfiFsqVKSbtr57Zx3NWem98ju7x+Qll1iOueociVK+sOrcrFTGyQXq GkXsnotzWTazFvgf67sfkmfzdmqZ3pPpze4cH5zDbM86vN5Qlh+j0yvos/Bbz3I5r0O2Fkos xRmJhlrMRcWJAGbq57bOAgAA Cc: OSPF List , IETF Secretariat Subject: [OSPF] Publication Request for "Use of OSPF-MDR in Single-Hop Broadcast Networks" 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, 04 Jun 2013 14:15:01 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_" --_000_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OSPF WG is requesting publication of "Use of OSPF-MDR in Single-Hop Bro= adcast Networks" (draft-ietf-ospf-manet-single-hop-mdr-03.txt). Acee Lindem= is acting as document shepherd and the attendant write-up is attached. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The OSPF WG is requesting publication of "Use= of OSPF-MDR in Single-Hop Broadcast Networks" (draft-ietf-ospf-manet-= single-hop-mdr-03.txt). Acee Lindem is acting as document shepherd and the = attendant write-up is attached.

Thanks,
Acee


--_000_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_ Content-Type: text/plain; name="ospf-wg-ospf-manet-single-hop-mdr-writeup.txt" Content-Description: ospf-wg-ospf-manet-single-hop-mdr-writeup.txt Content-Disposition: attachment; filename="ospf-wg-ospf-manet-single-hop-mdr-writeup.txt"; size=8529; creation-date="Tue, 04 Jun 2013 12:37:07 GMT"; modification-date="Tue, 04 Jun 2013 12:37:07 GMT" Content-ID: Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA1JbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gDXRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NDSAgICAg RXhwZXJpbWVudGFsLiANICAgICANICAgICBBcyBhbiB1cGRhdGUgb2YgUkZDNTYxNCwgYW4gRXhw ZXJpbWVudGFsIFJGQywgdGhpcyBkcmFmdCBpcyANICAgICBhbHNvIEV4cGVyaW1lbnRhbC4gDQ0o MikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5u b3VuY2VtZW50DVdyaXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3Vu Y2VtZW50IFdyaXRlLVVwLiBSZWNlbnQNZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0 aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA1kb2N1bWVudHMuIFRoZSBhcHByb3ZhbCBh bm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczoNDSAgICAgVGVjaG5p Y2FsIFN1bW1hcnkgDQ0gICAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBhcHBsaWNhdGlvbiBv ZiB0aGUgT1NQRiBNRFIgbWVjaGFuaXNtcyANICAgICB0byBzaW5nbGUtaG9wIGJyb2FkY2FzdCBu ZXR3b3Jrcy4gSXQgYWxzbyBpbmNsdWRlcyBzaW1wbGljYXRpb25zIA0gICAgIGZvciBNRFIgc2Vs ZWN0aW9uIGFuZCBSb3V0ZXItTFNBIG9yaWdpbmF0aW9uIG9uIHNpbmdsZS1ob3AgDSAgICAgYnJv YWRjYXN0IG5ldHdvcmtzLiANICAgICANICAgICBXb3JraW5nIEdyb3VwIFN1bW1hcnkgDQ0gICAg IFRoZSBpbml0aWFsIGRyYWZ0IHdhcyBhdXRob3JlZCBhYm91dCB0d28geWVhcnMgYWdvIGluIHJl c3BvbnNlDSAgICAgdG8gdGhlIE9TUEYgSHlicmlkIEludGVyZmFjZSBkcmFmdCBhbmQgT1NQRiBN QU5FVCBPUiBkcmFmdC4gDSAgICAgVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRo b3NlIGZhbWlsaWFyIHdpdGggT1NQRg0gICAgIE1BTkVUIGV4dGVuc2lvbnMuIFRoZXJlIGhhcyBi ZWVuIGxpdHRsZSBXRyBsYXN0IGNhbGwgZGlzY3Vzc2lvbi4NDSAgICAgQ29uc2VxdWVudGx5LCBK b2UgTWFja2VyIGFuZCBUb20gSGVuZGVyc29uIHdlcmUgcmVjcnVpdGVkIGFzIA0gICAgIHJldmll d2VycyBiYXNlZCBvbiB0aGVpciBNQU5FVCBrbm93bGVkZ2UgYW5kIGludm9sdmVtZW50IHdpdGgg DSAgICAgdGhlIG9yaWdpbmFsIE9TUEYgTUFORVQgd29yay4gQXMgdXBkYXRlZCB2ZXJzaW9uIHdh cyANICAgICBwdWJsaXNoZWQgYmFzZWQgdGhpcyByZXZpZXcuDSAgDSAgICAgRG9jdW1lbnQgUXVh bGl0eSANDSAgICAgVGhlIGRvY3VtZW50IGhhcyBnb25lIHRocm91Z2ggc2V2ZXJhbCBXRyByZXZp ZXcgY3ljbGVzIGFuZCANICAgICByZXZpc2lvbnMuIENvbW1lbnRzIHdlcmUgcmVjZWl2ZWQgZnJv bSBzb21lIFdHIG1lbWJlcnMuIFRoZXJlDSAgICAgYXJlIG5vIGltcGxlbWVudGF0aW9ucy4gDQ0g ICAgIFBlcnNvbm5lbCAgICAgIA0NICAgICBBY2VlIExpbmRlbSwgT1NQRiBXRyBjaGFpciwgaXMg dGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCANICAgICBTdGV3YXJ0IEJyeWFudCBpcyB0aGUgcmVz cG9uc2libGUgQUQuIA0NKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlzIGRv Y3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ10aGUgRG9jdW1lbnQgU2hlcGhlcmQuICBJZiB0 aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGlzIG5vdCByZWFkeQ1mb3IgcHVibGljYXRpb24s IHBsZWFzZSBleHBsYWluIHdoeSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRvDXRo ZSBJRVNHLg0NICAgICBBcyBkb2N1bWVudCBzaGVwaGVyZCwgSSByZXZpZXdlZCB0aGUgZG9jdW1l bnQgYXMgd2VsbCBhcyBzb2xpY2l0aW5nDSAgICAgaW5wdXQgZnJvbSBUb20gSGVuZGVyc29uIGFu ZCBKb2UgTWFja2VyLiANDSg0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBj b25jZXJucyBhYm91dCB0aGUgZGVwdGggb3INYnJlYWR0aCBvZiB0aGUgcmV2aWV3cyB0aGF0IGhh dmUgYmVlbiBwZXJmb3JtZWQ/IA0NICAgIE5vLiANDQ0oNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRv Y3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20NYnJvYWRlciBwZXJz cGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwgRE5T LA1ESENQLCBYTUwsIG9yIGludGVybmF0aW9uYWxpemF0aW9uPyBJZiBzbywgZGVzY3JpYmUgdGhl IHJldmlldyB0aGF0DXRvb2sgcGxhY2UuDQ0gICAgTm8uDQ0oNikgRGVzY3JpYmUgYW55IHNwZWNp ZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0IHRoZSBEb2N1bWVudCBTaGVwaGVyZA1oYXMgd2l0 aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgYW5kL29y IHRoZQ1JRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUgb3Ig c2hlIGlzIHVuY29tZm9ydGFibGUNd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwg b3IgaGFzIGNvbmNlcm5zIHdoZXRoZXIgdGhlcmUgcmVhbGx5DWlzIGEgbmVlZCBmb3IgaXQuIElu IGFueSBldmVudCwgaWYgdGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGhhcw1kaXNjdXNzZWQgdGhv c2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkIHRoYXQgaXQgc3RpbGwgd2lzaGVzIHRvIGFkdmFu Y2UNdGhlIGRvY3VtZW50LCBkZXRhaWwgdGhvc2UgY29uY2VybnMgaGVyZS4NDSAgIE5vbmUuIA0N KDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0 ZSBJUFINZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUg cHJvdmlzaW9ucyBvZiBCQ1AgNzgNYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4g SWYgbm90LCBleHBsYWluIHdoeS4NDSAgIFllcy4gICANDSg4KSBIYXMgYW4gSVBSIGRpc2Nsb3N1 cmUgYmVlbiBmaWxlZCB0aGF0IHJlZmVyZW5jZXMgdGhpcyBkb2N1bWVudD8NSWYgc28sIHN1bW1h cml6ZSBhbnkgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIElQUg1kaXNj bG9zdXJlcy4gICAgDQ0gICAgTm8uDQ0oOSkgSG93IHNvbGlkIGlzIHRoZSBjb25zZW5zdXMgb2Yg dGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGJlaGluZCB0aGlzDWRvY3VtZW50PyBEb2VzIGl0IHJl cHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1YWxzLA13aXRo IG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGFz IGEgd2hvbGUNdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gDQ0gICBUaGVyZSBpcyBubyBv cHBvc2l0aW9uIHRvIHRoZSBkcmFmdC4gVGhvc2Ugd2hvIHVuZGVyc3RhbmQNICAgdGhlIE1BTkVU IHVzZSBjYXNlcyBzdXBwb3J0IGV4dGVuZGluZyB0aGUgT1NQRiBNQU5FVCBzb2x1dGlvbiB0byAN ICAgb3B0aW1pemUgb3BlcmF0aW9uIG9uIHNpbmdsZS1ob3AgYnJvYWRjYXN0IG5ldHdvcmtzLiAN DSgxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNh dGVkIGV4dHJlbWUgDWRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVh cyBvZiBjb25mbGljdCBpbiBzZXBhcmF0ZQ1lbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2li bGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhDXNlcGFyYXRlIGVtYWlsIGJlY2F1 c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzIHB1YmxpY2x5IGF2YWlsYWJsZS4pIA0gDSAgIE5vLiAN DSgxMSkgSWRlbnRpZnkgYW55IElEIG5pdHMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBmb3Vu ZCBpbiB0aGlzDWRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRz LyBhbmQgdGhlIEludGVybmV0LURyYWZ0cw1DaGVja2xpc3QpLiBCb2lsZXJwbGF0ZSBjaGVja3Mg YXJlIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUNdGhvcm91Z2guDQ0gICBBbGwg YXBwbGljYWJsZSBpZG5pdHMgZXJyb3JzIGFuZCB3YXJuaW5ncyBoYXZlIGJlZW4gcmVzb2x2ZWQu DQ1pZG5pdHMgMi4xMi4xNiANDXRtcC9kcmFmdC1pZXRmLW9zcGYtbWFuZXQtc2luZ2xlLWhvcC1t ZHItMDIudHh0Og0NICBDaGVja2luZyBib2lsZXJwbGF0ZSByZXF1aXJlZCBieSBSRkMgNTM3OCBh bmQgdGhlIElFVEYgVHJ1c3QgKHNlZQ0gIGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut aW5mbyk6DSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NICAgICBObyBpc3N1ZXMgZm91bmQgaGVyZS4N DSAgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC1pbmZv LzFpZC1ndWlkZWxpbmVzLnR4dDoNICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0gICAgIE5vIGlzc3Vl cyBmb3VuZCBoZXJlLg0NICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwOi8vd3d3Lmll dGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoNICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0gIC0tIFRo ZSBkcmFmdCBoZWFkZXIgaW5kaWNhdGVzIHRoYXQgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzU2 MTQsIGJ1dCB0aGUNICAgICBhYnN0cmFjdCBkb2Vzbid0IHNlZW0gdG8gZGlyZWN0bHkgc2F5IHRo aXMuICBJdCBkb2VzIG1lbnRpb24gUkZDNTYxNA0gICAgIHRob3VnaCwgc28gdGhpcyBjb3VsZCBi ZSBPSy4NDQ0gIE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0N ICAgICAoVXNpbmcgdGhlIGNyZWF0aW9uIGRhdGUgZnJvbSBSRkM1NjE0LCB1cGRhdGVkIGJ5IHRo aXMgZG9jdW1lbnQsIGZvcg0gICAgIFJGQzUzNzggY2hlY2tzOiAyMDA4LTAyLTE2KQ0NICAtLSBU aGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayBhIGRpc2NsYWltZXIgZm9yIHByZS1SRkM1Mzc4IHdv cmssIGJ1dCBtYXkNICAgICBoYXZlIGNvbnRlbnQgd2hpY2ggd2FzIGZpcnN0IHN1Ym1pdHRlZCBi ZWZvcmUgMTAgTm92ZW1iZXIgMjAwOC4gIElmIHlvdQ0gICAgIGhhdmUgY29udGFjdGVkIGFsbCB0 aGUgb3JpZ2luYWwgYXV0aG9ycyBhbmQgdGhleSBhcmUgYWxsIHdpbGxpbmcgdG8gZ3JhbnQNICAg ICB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJRVRGIFRydXN0LCB0aGVuIHRoaXMgaXMgZmluZSwg YW5kIHlvdSBjYW4gaWdub3JlDSAgICAgdGhpcyBjb21tZW50LiAgSWYgbm90LCB5b3UgbWF5IG5l ZWQgdG8gYWRkIHRoZSBwcmUtUkZDNTM3OCBkaXNjbGFpbWVyLiANICAgICAoU2VlIHRoZSBMZWdh bCBQcm92aXNpb25zIGRvY3VtZW50IGF0DSAgICAgaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGlj ZW5zZS1pbmZvIGZvciBtb3JlIGluZm9ybWF0aW9uLikNDSAgLS0gVGhlIGRvY3VtZW50IGRhdGUg KE1heSA1LCAyMDEzKSBpcyAxOCBkYXlzIGluIHRoZSBwYXN0LiAgSXMgdGhpcw0gICAgIGludGVu dGlvbmFsPw0NDSAgQ2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBFeHBl cmltZW50YWwNICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0gICAgIE5vIGlzc3VlcyBmb3VuZCBoZXJl Lg0NICAgICBTdW1tYXJ5OiAwIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDAgd2FybmluZ3Mg KD09KSwgMyBjb21tZW50cyAoLS0pLg0NICAgICBSdW4gaWRuaXRzIHdpdGggdGhlIC0tdmVyYm9z ZSBvcHRpb24gZm9yIG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gYWJvdXQNICAgICB0aGUgaXRl bXMgYWJvdmUuDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0NKDEyKSBEZXNjcmliZSBob3cgdGhl IGRvY3VtZW50IG1lZXRzIGFueSByZXF1aXJlZCBmb3JtYWwgcmV2aWV3DWNyaXRlcmlhLCBzdWNo IGFzIHRoZSBNSUIgRG9jdG9yLCBtZWRpYSB0eXBlLCBhbmQgVVJJIHR5cGUgcmV2aWV3cy4NDSAg IE5vdCBhcHBsaWNhYmxlLiANDSgxMykgSGF2ZSBhbGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBk b2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXMNZWl0aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2 ZT8NDSAgIFllcy4NDSgxNCkgQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3Vt ZW50cyB0aGF0IGFyZSBub3QgcmVhZHkgZm9yDWFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2Ug aW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUNcmVmZXJlbmNlcyBleGlzdCwg d2hhdCBpcyB0aGUgcGxhbiBmb3IgdGhlaXIgY29tcGxldGlvbj8NDSAgICBOby4gDQ0oMTUpIEFy ZSB0aGVyZSBkb3dud2FyZCBub3JtYXRpdmUgcmVmZXJlbmNlcyByZWZlcmVuY2VzIChzZWUgUkZD IDM5NjcpPw1JZiBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQg dGhlIEFyZWEgRGlyZWN0b3IgaW4NdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUuDQ0gICAgTm8uDQ0o MTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBv ZiBhbnkgZXhpc3RpbmcNUkZDcz8gQXJlIHRob3NlIFJGQ3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBw YWdlIGhlYWRlciwgbGlzdGVkIGluIHRoZQ1hYnN0cmFjdCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUg aW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90IGxpc3RlZA1pbiB0aGUgQWJzdHJhY3Qg YW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUgcGFydCBvZg10 aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IHRvIHRo ZSBvdGhlciBSRkNzDWlzIGRpc2N1c3NlZC4gSWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgaW4g dGhlIGRvY3VtZW50LCBleHBsYWluIHdoeQ10aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgY29uc2lk ZXJzIGl0IHVubmVjZXNzYXJ5Lg0NICAgIE5vLiANDSgxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50 IFNoZXBoZXJkJ3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zDXNlY3Rpb24sIGVz cGVjaWFsbHkgd2l0aCByZWdhcmQgdG8gaXRzIGNvbnNpc3RlbmN5IHdpdGggdGhlIGJvZHkgb2Yg dGhlDWRvY3VtZW50LiBDb25maXJtIHRoYXQgYWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0 aGUgZG9jdW1lbnQgbWFrZXMNYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVz ZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmllcy4NQ29uZmlybSB0aGF0IGFueSByZWZlcmVuY2Vk IElBTkEgcmVnaXN0cmllcyBoYXZlIGJlZW4gY2xlYXJseQ1pZGVudGlmaWVkLiBDb25maXJtIHRo YXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhDWRldGFpbGVkIHNwZWNp ZmljYXRpb24gb2YgdGhlIGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3RyeSwgdGhhdA1h bGxvY2F0aW9ucyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucyBhcmUgZGVmaW5l ZCwgYW5kIGENcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1 Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4NDSAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgcmVxdWly ZSBhbnkgSUFOQSBhY3Rpb25zLg0NKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRo YXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvciBmdXR1cmUNYWxsb2NhdGlvbnMuIFByb3ZpZGUg YW55IHB1YmxpYyBndWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQNdXNlZnVsIGluIHNl bGVjdGluZyB0aGUgSUFOQSBFeHBlcnRzIGZvciB0aGVzZSBuZXcgcmVnaXN0cmllcy4NDSAgICAg Tm9uZS4gIA0NDSgxOSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJm b3JtZWQgYnkgdG8gdmFsaWRhdGUNc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4g YSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsDUJORiBydWxlcywgTUlCIGRlZmlu aXRpb25zLCBldGMuDQ0gICAgIE5vdCBBcHBsaWNhYmxlLiAN --_004_94A203EA12AECE4BA92D42DBFFE0AE4715B435eusaamb101ericsso_-- From iesg-secretary@ietf.org Wed Jun 5 08:09:55 2013 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 C0C9421F99ED; Wed, 5 Jun 2013 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 6XlnItVFi3ya; Wed, 5 Jun 2013 08:09:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4121F89A5; Wed, 5 Jun 2013 08:09:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 08:09:55 -0700 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:09:56 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ No IPR declarations have been submitted directly on this I-D. From sratliff@cisco.com Thu Jun 6 07:22:42 2013 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 8DEF421F93E0; Thu, 6 Jun 2013 07:22:41 -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 5+cy6Mx1dWD4; Thu, 6 Jun 2013 07:22:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E721F972C; Thu, 6 Jun 2013 07:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3350; q=dns/txt; s=iport; t=1370528539; x=1371738139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H92TswpvTGdoPsd51P2IQXW0U6iWsH8qwElUXgklU+Y=; b=EMMHiKi/l8KXl5jqJcCU/Z8xFlwYEshIFPh3ZWFMEUeSpTFrd0U4V/97 UZM86aTCcLDiV0C4Htl1delrwBopMIn8OP75FG0JAaGBm7LOShI/ucBtT NmJzCPFg9boK4EKVvRCvQO/Z7MB5NM3tpTpYOtd4bowPme4MyqkV1nFOQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAPeZsFGtJXG9/2dsb2JhbABZgwkwv0d4FnSCIwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAUEBycLFAkIAgQBDQUIDIdzBgy7LI1wgQ8CMQcGgnRhA5hokBeBWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219580324" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 14:22:18 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56EMIBd000867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 14:22:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 09:22:17 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun , OSPF List , Acee Lindem Thread-Topic: [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC Thread-Index: AQHOYsE/Z1NEPUx3SkSpfeeEjarimg== Date: Thu, 6 Jun 2013 14:22:16 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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, 06 Jun 2013 14:22:43 -0000 Abdussalam,=20 I'm forwarding your email to the OSPF mailing list and Acee Lindem (the doc= ument shepherd). Just FYI, no one on the MANET list has responded since thi= s is an OSPF issue.=20 Regards, Stan On Jun 6, 2013, at 6:20 AM, Abdussalam Baryun wrote: > Dear IETF AD, >=20 > I hope that my questions are to be answered. Please note that I don't > think I have to remind editors even if they are busy, because I am > busy as well. IMHO, if an editor is busy or not able to reply to > community he/she should not take any work of the IETF. Please note > that this is a public complain from me about the editors of this I-D > not answering to my questions. >=20 > AB >=20 > On 6/6/13, Adrian Farrel wrote: >> Heads up. >>=20 >> This I-D is in IETF last call. >>=20 >> I know some of you had comments on a previous version. Please send any >> further >> comments as described for IETF last call and *NOT* to this list. >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >>> bounces@ietf.org] On Behalf Of The IESG >>> Sent: 05 June 2013 16:10 >>> To: IETF-Announce >>> Cc: ospf@ietf.org >>> Subject: Last Call: (Use = of >> OSPF- >>> MDR in Single-Hop Broadcast Networks) to Experimental RFC >>>=20 >>>=20 >>> The IESG has received a request from the Open Shortest Path First IGP W= G >>> (ospf) to consider the following document: >>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' >>> as Experimental RFC >>>=20 >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may = be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>>=20 >>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks >>> (MANETs) by specifying its operation on the new OSPF interface of type >>> MANET. This document describes the use of OSPF-MDR in a single-hop >>> broadcast network, which is a special case of a MANET in which each >>> router is a (one-hop) neighbor of each other router. Unlike an OSPF >>> broadcast interface, such an interface can have a different cost >>> associated with each neighbor. The document includes configuration >>> recommendations and simplified mechanisms that can be used in single-ho= p >>> broadcast networks. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ >>>=20 >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ba= llot/ >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From prvs=9869d7c2d2=acee.lindem@ericsson.com Thu Jun 6 07:54:06 2013 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 B447321F9051; Thu, 6 Jun 2013 07:54:06 -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 MY+nE9iLrUBE; Thu, 6 Jun 2013 07:54:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7C21F909A; Thu, 6 Jun 2013 07:54:01 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-e3-51b0a288ecdf Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.20.17537.882A0B15; Thu, 6 Jun 2013 16:54:00 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 10:53:59 -0400 From: Acee Lindem To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC Thread-Index: AQHOYsFKTfUt5Sz74UK8tC8DlKruYpkpCOEA Date: Thu, 6 Jun 2013 14:53:59 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715D995@eusaamb101.ericsson.se> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D8E8128D3A6AB4A93A654C8BE56BB7F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonQbdj0YZAg1PPjSy+3WhlsvjRc4PZ 4t+WJ+wWLffusVusfv+I3YHVY8rvjaweO2fdZfdYsuQnk8eKzSsZA1iiuG2SEkvKgjPT8/Tt Ergzfr+7zliwVLZi2cMG9gbGNokuRk4OCQETiXd3v7BC2GISF+6tZ+ti5OIQEjjKKHHq8VJ2 CGcZo8TXjR1sIFVsAjoSzx/9YwaxRQSMJFY928gIUsQsMIdRYm/LJLB2YYEZjBLXru1kgaia ySjR/9EVpuPq8gWMIDaLgIpE475vYFN5BbwlTq05xgSx7g+jxL1Db9hBEpwCvhJrJl9kArEZ gQ78fmoNmM0sIC5x68l8JojDBSSW7DnPDGGLSrx8/A/qIWWJJU/2s0DU60gs2P2JDcK2lthz +C4jhK0tsWzha2aIIwQlTs58wjKBUXwWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxls YgRG5DEJNt0djHteWh5ilOZgURLnVeNdHCgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDE0RwSTUw ugbOD3t0xmfJ3z2btT2Y8/gW7rz2jVtFn1uy5unZPU5bLok9iNozZ+f3xT2XWH8s7xHs0fsi 3Lt7w2mTs3Wanrz1XTkivyqTDSf+MfTazRji2t328+jFpd5XbhXM+mD+QIGtqVqWy9HdvLAg IVKhuuzkD2bVFrcOyxCpY44ild1m3haGc/8osRRnJBpqMRcVJwIAOjhxapsCAAA= Cc: OSPF List , "manet@ietf.org List" , Abdussalam Baryun Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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, 06 Jun 2013 14:54:06 -0000 Abdussalam,=20 Your questions on this OSPF WG document were not posted to the OSPF list. H= ence, your "public complaint" is completely without merit. Please refer to = RFC 2026, section 1.2.=20 Thanks, Acee=20 On Jun 6, 2013, at 10:22 AM, Stan Ratliff (sratliff) wrote: > Abdussalam,=20 >=20 > I'm forwarding your email to the OSPF mailing list and Acee Lindem (the d= ocument shepherd). Just FYI, no one on the MANET list has responded since t= his is an OSPF issue.=20 >=20 > Regards, > Stan >=20 > On Jun 6, 2013, at 6:20 AM, Abdussalam Baryun wrote: >=20 >> Dear IETF AD, >>=20 >> I hope that my questions are to be answered. Please note that I don't >> think I have to remind editors even if they are busy, because I am >> busy as well. IMHO, if an editor is busy or not able to reply to >> community he/she should not take any work of the IETF. Please note >> that this is a public complain from me about the editors of this I-D >> not answering to my questions. >>=20 >> AB >>=20 >> On 6/6/13, Adrian Farrel wrote: >>> Heads up. >>>=20 >>> This I-D is in IETF last call. >>>=20 >>> I know some of you had comments on a previous version. Please send any >>> further >>> comments as described for IETF last call and *NOT* to this list. >>>=20 >>> Thanks, >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >>>> bounces@ietf.org] On Behalf Of The IESG >>>> Sent: 05 June 2013 16:10 >>>> To: IETF-Announce >>>> Cc: ospf@ietf.org >>>> Subject: Last Call: (Use= of >>> OSPF- >>>> MDR in Single-Hop Broadcast Networks) to Experimental RFC >>>>=20 >>>>=20 >>>> The IESG has received a request from the Open Shortest Path First IGP = WG >>>> (ospf) to consider the following document: >>>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' >>>> as Experimental RFC >>>>=20 >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may= be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks >>>> (MANETs) by specifying its operation on the new OSPF interface of type >>>> MANET. This document describes the use of OSPF-MDR in a single-hop >>>> broadcast network, which is a special case of a MANET in which each >>>> router is a (one-hop) neighbor of each other router. Unlike an OSPF >>>> broadcast interface, such an interface can have a different cost >>>> associated with each neighbor. The document includes configuration >>>> recommendations and simplified mechanisms that can be used in single-h= op >>>> broadcast networks. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ >>>>=20 >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/b= allot/ >>>>=20 >>>>=20 >>>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From prvs=28698b8dde=acee.lindem@ericsson.com Thu Jun 6 08:44:58 2013 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 0548B21F99EC for ; Thu, 6 Jun 2013 08:44:58 -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 OKvdtkWtZJ1g for ; Thu, 6 Jun 2013 08:44:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47421F9193 for ; Thu, 6 Jun 2013 08:44:52 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-14-51b0ae730970 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 24.F0.05617.37EA0B15; Thu, 6 Jun 2013 17:44:51 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 11:44:51 -0400 From: Acee Lindem To: Abdussalam Baryun Thread-Topic: [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC Thread-Index: AQHOYsFKTfUt5Sz74UK8tC8DlKruYpkpCOEAgAAFKQCAAAkMgA== Date: Thu, 6 Jun 2013 15:44:50 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715DA3B@eusaamb101.ericsson.se> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4715D995@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <610535DE10598F449CA0411A58852AA7@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPgm7xug2BBmfP61t8u9HKZNFy7x67 A5PHzll32T2WLPnJFMAUxW2TlFhSFpyZnqdvl8Cd8aelmbXgg2rF5vU9jA2M/+W6GDk5JARM JHbMeMgEYYtJXLi3nq2LkYtDSOAoo8Sz1a1MEM4yRom2i49ZQKrYBHQknj/6xwxiiwgYSSz9 vYUNxGYWkJV4tq2JGaRBWGAGo8S1aztZIIpmMkr0f3SFsJ0kOp5tYwSxWQRUJG4fmgi2mlfA W+LUr7VQq1uZJTY8bQRLcAoESkzb9wDMZgS67/upNUwQ28Qlbj2ZD3W3gMSSPeeZIWxRiZeP /7FC2MoSS57sZ4Go15FYsPsT1KXWEvN/HmCHsLUlli18zQxxhKDEyZlPWCYwis9CsmIWkvZZ SNpnIWmfhaR9ASPrKkaO0uLUstx0I8NNjMDoOibB5riDccEny0OM0hwsSuK8OryLA4UE0hNL UrNTUwtSi+KLSnNSiw8xMnFwggguqQZGjzv3T3812sFmtqei+MONyJMsi5uv+bXPZV37UuKf 68W1SfeV4i5HXUy+cXkl62uP4HjVg8GfWsR+uBXteFnj51gilPXEcnu47C1u3vtsHq37Hsqr 6W7/vG124NmEN8ezT8qdrf6ndPrqZx6LXoWzT38duOuZWrGQx2WnzoRe+d+ecVVu4s08SizF GYmGWsxFxYkAhMw9AoECAAA= Cc: OSPF List Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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, 06 Jun 2013 15:44:58 -0000 Even when we WG call a document in multiple WGs, the comments need to be po= sted in the draft's home WG. Given that there are 8 or so WGs that have aff= inity with OSPF, I do not follow all of them.=20 Thanks, Acee=20 On Jun 6, 2013, at 11:12 AM, Abdussalam Baryun wrote: > Hi Acee, >=20 > The draft is about MANET as well as OSPF, so I posted to the author > address my questions including the MANET list. I may agree that I > should have send also to OSPF, but also think that OSPF should have > send collaboration request with MANET WG from the start of the work. I > understoond that there was collaboration between WG Chairs, but why > not the participants of both WGs. Don't we all work in the same IETF? > Please advise, >=20 > AB >=20 > On 6/6/13, Acee Lindem wrote: >> Abdussalam, >>=20 >> Your questions on this OSPF WG document were not posted to the OSPF list= . >> Hence, your "public complaint" is completely without merit. Please refer= to >> RFC 2026, section 1.2. >>=20 >> Thanks, >> Acee >>=20 >> On Jun 6, 2013, at 10:22 AM, Stan Ratliff (sratliff) wrote: >>=20 >>> Abdussalam, >>>=20 >>> I'm forwarding your email to the OSPF mailing list and Acee Lindem (the >>> document shepherd). Just FYI, no one on the MANET list has responded si= nce >>> this is an OSPF issue. >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Jun 6, 2013, at 6:20 AM, Abdussalam Baryun wrote: >>>=20 >>>> Dear IETF AD, >>>>=20 >>>> I hope that my questions are to be answered. Please note that I don't >>>> think I have to remind editors even if they are busy, because I am >>>> busy as well. IMHO, if an editor is busy or not able to reply to >>>> community he/she should not take any work of the IETF. Please note >>>> that this is a public complain from me about the editors of this I-D >>>> not answering to my questions. >>>>=20 >>>> AB >>>>=20 >>>> On 6/6/13, Adrian Farrel wrote: >>>>> Heads up. >>>>>=20 >>>>> This I-D is in IETF last call. >>>>>=20 >>>>> I know some of you had comments on a previous version. Please send an= y >>>>> further >>>>> comments as described for IETF last call and *NOT* to this list. >>>>>=20 >>>>> Thanks, >>>>> Adrian >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >>>>>> bounces@ietf.org] On Behalf Of The IESG >>>>>> Sent: 05 June 2013 16:10 >>>>>> To: IETF-Announce >>>>>> Cc: ospf@ietf.org >>>>>> Subject: Last Call: (U= se >>>>>> of >>>>> OSPF- >>>>>> MDR in Single-Hop Broadcast Networks) to Experimental RFC >>>>>>=20 >>>>>>=20 >>>>>> The IESG has received a request from the Open Shortest Path First IG= P >>>>>> WG >>>>>> (ospf) to consider the following document: >>>>>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' >>>>>> as Experimental RFC >>>>>>=20 >>>>>> The IESG plans to make a decision in the next few weeks, and solicit= s >>>>>> final comments on this action. Please send substantive comments to t= he >>>>>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments m= ay >>>>>> be >>>>>> sent to iesg@ietf.org instead. In either case, please retain the >>>>>> beginning of the Subject line to allow automated sorting. >>>>>>=20 >>>>>> Abstract >>>>>>=20 >>>>>>=20 >>>>>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks >>>>>> (MANETs) by specifying its operation on the new OSPF interface of ty= pe >>>>>> MANET. This document describes the use of OSPF-MDR in a single-hop >>>>>> broadcast network, which is a special case of a MANET in which each >>>>>> router is a (one-hop) neighbor of each other router. Unlike an OSPF >>>>>> broadcast interface, such an interface can have a different cost >>>>>> associated with each neighbor. The document includes configuration >>>>>> recommendations and simplified mechanisms that can be used in >>>>>> single-hop >>>>>> broadcast networks. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The file can be obtained via >>>>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr= / >>>>>>=20 >>>>>> IESG discussion can be tracked via >>>>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr= /ballot/ >>>>>>=20 >>>>>>=20 >>>>>> No IPR declarations have been submitted directly on this I-D. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 From mjbarnes@cisco.com Thu Jun 6 13:12:16 2013 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 C6E2F21F96DE for ; Thu, 6 Jun 2013 13:12:16 -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 qth8AmWiez0z for ; Thu, 6 Jun 2013 13:12:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6468C21F96EB for ; Thu, 6 Jun 2013 13:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3504; q=dns/txt; s=iport; t=1370549532; x=1371759132; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ln/TN37D1pHrTaodJom2HvFK31Hq6CXyCTrNNOTDcak=; b=WUfMBYHCihLPSNGUBltKbOoqZV+N54BI4qJ2mVIy/+5/Av28xvPsML49 Cv5JNpjQdLgiwwC7idOWvrX0sjz35jZpUY0T/u67fx+/MgdUQyLIkX/XC F+Teoeb5lvfVDhhxoBOP6Nbt6nmwuAvn/867qslNIx2ZOr7PY7W9OZgqp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAPTrsFGrRDoG/2dsb2JhbABZgwkwAUK/B3oWdIIjAQEBBAEBATU2CQERCxgJDAoPCQMCAQIBFTATBgIBAQULh3gIBbtRjzkKg1EDiSCKTYNSgSmEdYsigy8c X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="82913805" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Jun 2013 20:12:11 +0000 Received: from [10.21.149.43] (sjc-vpn7-1323.cisco.com [10.21.149.43]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56KC3fp009978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jun 2013 20:12:09 GMT Message-ID: <51B0ED10.1090007@cisco.com> Date: Thu, 06 Jun 2013 13:12:00 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ospf@ietf.org References: <20130509174336.13252.85872.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4713F940@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4713F940@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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, 06 Jun 2013 20:12:16 -0000 I agree these are good changes. Acee, please move forward with this draft. Thanks, Michael On 05/09/2013 11:03 AM, Acee Lindem wrote: > There have been a couple errata filed on RFC 6505 (authors copied). As a service to the > OSPF community and in an effort to ensure interoperable OSPFv3 authentication > trailer implementations, I have produced a BIS draft. The changes are listed in > section 1.2: > > 1.2. Summary of Changes from RFC 6506 > > This document includes the following changes from RFC 6506 [RFC6506]: > > 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling > (LLS) block checksum calculation is omitted when an OSPFv3 > authentication is used. The LLS block is included in the > authentication digest calculation and computation of a checksum > is unneccessary. Clarification of this issue was raised in an > errata. > > 2. Section 4.5 includes a correction to the key preparation to use > the protocol specific key (Ks) rather than the key (K) as the > initial key (Ko). This problem was also raised in an errata. > > 3. Section 4.5 also includes a discussion of the choice of key > length to be the hash length (L) rather than the block size (B). > The discussion of this choice was included to clarify an issue > raised in a rejected errata. > > 4. Section 4.1 indicates that sequence number checking is dependent > on OSPFv3 packet type in order to account for packet > prioritization as specified in [RFC4222]. This was an omission > from RFC 6506. > > > I would like to quickly move this to an OSPF WG document and begin the review process. I'm now soliciting feedback on OSPF WG adoption. > > Thanks, > Acee > > > On May 9, 2013, at 1:43 PM, > wrote: > >> >> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt >> has been successfully submitted by Manav Bhatia and posted to the >> IETF repository. >> >> Filename: draft-acee-ospf-rfc6506bis >> Revision: 01 >> Title: Supporting Authentication Trailer for OSPFv3 >> Creation date: 2013-05-09 >> Group: Individual Submission >> Number of pages: 25 >> URL: http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >> Status: http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >> Htmlized: http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-acee-ospf-rfc6506bis-01 >> >> Abstract: >> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >> for authenticating protocol packets. This behavior is different from >> authentication mechanisms present in other routing protocols (OSPFv2, >> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >> Information Protocol Next Generation (RIPng)). In some environments, >> it has been found that IPsec is difficult to configure and maintain >> and thus cannot be used. This document defines an alternative >> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does >> not only depend upon IPsec for authentication. This document >> obsoletes RFC 6506. >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From wwwrun@rfc-editor.org Fri Jun 7 12:48:21 2013 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 BEA4321F9798 for ; Fri, 7 Jun 2013 12:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.375 X-Spam-Level: X-Spam-Status: No, score=-101.375 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, MANGLED_NAIL=2.3, NO_RELAYS=-0.001, 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 a0kltEB6ggkK for ; Fri, 7 Jun 2013 12:48:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9641921F96E4 for ; Fri, 7 Jun 2013 12:48:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DFE7B62114; Fri, 7 Jun 2013 12:46:49 -0700 (PDT) To: jmoy@casc.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130607194649.DFE7B62114@rfc-editor.org> Date: Fri, 7 Jun 2013 12:46:49 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org, preet.desouza17@gmail.com Subject: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Fri, 07 Jun 2013 19:48:21 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3644 -------------------------------------- Type: Technical Reported by: Preet D'Souza Section: 2.1.2 Original Text ------------- **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Corrected Text -------------- **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Ia| | | | | | | | | |5 | | | | | | | Ib| | | | | |7 | | | | | | | | | | | Notes ----- section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. The interfaces Ia and Ib have not been added to the directed graph. By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT6 should advertise a stub network to Ia . Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee@lindem.com Fri Jun 7 12:59:56 2013 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 83C0221F996A for ; Fri, 7 Jun 2013 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3] 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 Rm67wXj73WSj for ; Fri, 7 Jun 2013 12:59:52 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id CBBBF21F9969 for ; Fri, 7 Jun 2013 12:59:51 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=ffsvOjsF c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=qIV9paJqKZ0A:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=Zj9u1qtRmtYA:10 a=BqEg4_3jAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=OSzkMb4IVOTMhISXKQwA:9 a=CjuIK1q_8ugA:10 a=mhd2NDuUijAA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:64642] helo=[192.168.1.107]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 05/2F-07131-5BB32B15; Fri, 07 Jun 2013 19:59:50 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <20130607194649.DFE7B62114@rfc-editor.org> Date: Fri, 7 Jun 2013 15:59:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130607194649.DFE7B62114@rfc-editor.org> To: preet.desouza17@gmail.com X-Mailer: Apple Mail (2.1085) Cc: jmoy@casc.com, RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Fri, 07 Jun 2013 19:59:56 -0000 Preet - Can you denote which boxes you changed and why? In its current = state, this errata should be summarily rejected.=20 Thanks, Acee=20 On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3644 >=20 > -------------------------------------- > Type: Technical > Reported by: Preet D'Souza >=20 > Section: 2.1.2 >=20 > Original Text > ------------- > **FROM** >=20 > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| > ----- --------------------------------------------- > RT1| | | | | | | | | | | | |0 | | | | > RT2| | | | | | | | | | | | |0 | | | | > RT3| | | | | |6 | | | | | | |0 | | | | > RT4| | | | |8 | | | | | | | |0 | | | | > RT5| | | |8 | |6 |6 | | | | | | | | | | > RT6| | |8 | |7 | | | | |5 | | | | | | | > RT7| | | | |6 | | | | | | | | |0 | | | > * RT8| | | | | | | | | | | | | |0 | | | > * RT9| | | | | | | | | | | | | | | |0 | > T RT10| | | | | |7 | | | | | | | |0 |0 | | > O RT11| | | | | | | | | | | | | | |0 |0 | > * RT12| | | | | | | | | | | | | | | |0 | > * N1|3 | | | | | | | | | | | | | | | | > N2| |3 | | | | | | | | | | | | | | | > N3|1 |1 |1 |1 | | | | | | | | | | | | | > N4| | |2 | | | | | | | | | | | | | | > N6| | | | | | |1 |1 | |1 | | | | | | | > N7| | | | | | | |4 | | | | | | | | | > N8| | | | | | | | | |3 |2 | | | | | | > N9| | | | | | | | |1 | |1 |1 | | | | | > N10| | | | | | | | | | | |2 | | | | | > N11| | | | | | | | |3 | | | | | | | | > N12| | | | |8 | |2 | | | | | | | | | | > N13| | | | |8 | | | | | | | | | | | | > N14| | | | |8 | | | | | | | | | | | | > N15| | | | | | |9 | | | | | | | | | | > H1| | | | | | | | | | | |10| | | | | >=20 >=20 > Corrected Text > -------------- > **FROM** >=20 > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| > ----- --------------------------------------------- > RT1| | | | | | | | | | | | |0 | | | | > RT2| | | | | | | | | | | | |0 | | | | > RT3| | | | | |6 | | | | | | |0 | | | | > RT4| | | | |8 | | | | | | | |0 | | | | > RT5| | | |8 | |6 |6 | | | | | | | | | | > RT6| | |8 | |7 | | | | |5 | | | | | | | > RT7| | | | |6 | | | | | | | | |0 | | | > * RT8| | | | | | | | | | | | | |0 | | | > * RT9| | | | | | | | | | | | | | | |0 | > T RT10| | | | | |7 | | | | | | | |0 |0 | | > O RT11| | | | | | | | | | | | | | |0 |0 | > * RT12| | | | | | | | | | | | | | | |0 | > * N1|3 | | | | | | | | | | | | | | | | > N2| |3 | | | | | | | | | | | | | | | > N3|1 |1 |1 |1 | | | | | | | | | | | | | > N4| | |2 | | | | | | | | | | | | | | > N6| | | | | | |1 |1 | |1 | | | | | | | > N7| | | | | | | |4 | | | | | | | | | > N8| | | | | | | | | |3 |2 | | | | | | > N9| | | | | | | | |1 | |1 |1 | | | | | > N10| | | | | | | | | | | |2 | | | | | > N11| | | | | | | | |3 | | | | | | | | > N12| | | | |8 | |2 | | | | | | | | | | > N13| | | | |8 | | | | | | | | | | | | > N14| | | | |8 | | | | | | | | | | | | > N15| | | | | | |9 | | | | | | | | | | > H1| | | | | | | | | | | |10| | | | | > Ia| | | | | | | | | |5 | | | | | | | > Ib| | | | | |7 | | | | | | | | | | | >=20 > Notes > ----- > section 2.1.2 >=20 > Page 20, Figure 2 : A sample Autonomous System. >=20 > The interfaces Ia and Ib have not been added to the directed = graph. > By definition of point-to-point links under OSPF, for serial = interfaces defined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router RT6 = should advertise a stub network to Ia . >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From preet.desouza17@gmail.com Fri Jun 7 13:29:52 2013 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 D706221F9950 for ; Fri, 7 Jun 2013 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-1] 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 O2P+-0WYolaR for ; Fri, 7 Jun 2013 13:29:49 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id AFEC421F995F for ; Fri, 7 Jun 2013 13:29:48 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so3064489qeb.29 for ; Fri, 07 Jun 2013 13:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qDDx+UqP4WOcrS0tAT17iiKFqfcjH+tVPCWbFYTjHFc=; b=BNV5HdzaFNIEoBh6AS9kGE4qUN0UBfvOv+QP8YwMLKIEdKM7duGl2V5nMQ1g/nOCuq mtwd4cNCOMIE24XrtrQ/pvb9XKZolBOV1Qdt/rGZcCE6ETBUBILuI5w37aR1W79jm1fZ Soqx6fouxTYMm9kC+klJ2UNS0ch3yu/0pdyWE8vOj3FVZRigUtOUNBpPp6wLaou44Lne Hqbzw0u2JfNvKSwxpWtTe8J6qFIAqdu/VPgInt/0dLmhCaE5XkvIyNRQx7yk+DHA9guc lUF71yNu7FH/7LbMEbwEq7dEe9Kx6P+A37qMcHHz3M9ZQPcRTp3AgnHxFqKcZbiwk1DO aPDg== MIME-Version: 1.0 X-Received: by 10.49.24.198 with SMTP id w6mr346528qef.58.1370636988068; Fri, 07 Jun 2013 13:29:48 -0700 (PDT) Received: by 10.224.74.2 with HTTP; Fri, 7 Jun 2013 13:29:48 -0700 (PDT) In-Reply-To: References: <20130607194649.DFE7B62114@rfc-editor.org> Date: Sat, 8 Jun 2013 01:59:48 +0530 Message-ID: From: Preet DSouza To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b5d8e79ca91d104de964ae3 Cc: jmoy@casc.com, RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Fri, 07 Jun 2013 20:29:53 -0000 --047d7b5d8e79ca91d104de964ae3 Content-Type: text/plain; charset=ISO-8859-1 The corrected text should be as under. The additions are noted in bold. **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | *Ia| | | | | | | | | |5 | | | | | | |** Ib| | | | | |7 | | | | | | | | | | |* On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza wrote: > Hello Acee, > > I made two additions. > The last two rows in the **To** column have been added. > They are interfaces Ia and Ib which are represented as stub networks > owing to their definition on a point-to-point link between RT6 and RT10 > > > On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem wrote: > >> Preet - Can you denote which boxes you changed and why? In its current >> state, this errata should be summarily rejected. >> Thanks, >> Acee >> On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: >> >> > The following errata report has been submitted for RFC2328, >> > "OSPF Version 2". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3644 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Preet D'Souza >> > >> > Section: 2.1.2 >> > >> > Original Text >> > ------------- >> > **FROM** >> > >> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >> > ----- --------------------------------------------- >> > RT1| | | | | | | | | | | | |0 | | | | >> > RT2| | | | | | | | | | | | |0 | | | | >> > RT3| | | | | |6 | | | | | | |0 | | | | >> > RT4| | | | |8 | | | | | | | |0 | | | | >> > RT5| | | |8 | |6 |6 | | | | | | | | | | >> > RT6| | |8 | |7 | | | | |5 | | | | | | | >> > RT7| | | | |6 | | | | | | | | |0 | | | >> > * RT8| | | | | | | | | | | | | |0 | | | >> > * RT9| | | | | | | | | | | | | | | |0 | >> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >> > O RT11| | | | | | | | | | | | | | |0 |0 | >> > * RT12| | | | | | | | | | | | | | | |0 | >> > * N1|3 | | | | | | | | | | | | | | | | >> > N2| |3 | | | | | | | | | | | | | | | >> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >> > N4| | |2 | | | | | | | | | | | | | | >> > N6| | | | | | |1 |1 | |1 | | | | | | | >> > N7| | | | | | | |4 | | | | | | | | | >> > N8| | | | | | | | | |3 |2 | | | | | | >> > N9| | | | | | | | |1 | |1 |1 | | | | | >> > N10| | | | | | | | | | | |2 | | | | | >> > N11| | | | | | | | |3 | | | | | | | | >> > N12| | | | |8 | |2 | | | | | | | | | | >> > N13| | | | |8 | | | | | | | | | | | | >> > N14| | | | |8 | | | | | | | | | | | | >> > N15| | | | | | |9 | | | | | | | | | | >> > H1| | | | | | | | | | | |10| | | | | >> > >> > >> > Corrected Text >> > -------------- >> > **FROM** >> > >> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >> > ----- --------------------------------------------- >> > RT1| | | | | | | | | | | | |0 | | | | >> > RT2| | | | | | | | | | | | |0 | | | | >> > RT3| | | | | |6 | | | | | | |0 | | | | >> > RT4| | | | |8 | | | | | | | |0 | | | | >> > RT5| | | |8 | |6 |6 | | | | | | | | | | >> > RT6| | |8 | |7 | | | | |5 | | | | | | | >> > RT7| | | | |6 | | | | | | | | |0 | | | >> > * RT8| | | | | | | | | | | | | |0 | | | >> > * RT9| | | | | | | | | | | | | | | |0 | >> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >> > O RT11| | | | | | | | | | | | | | |0 |0 | >> > * RT12| | | | | | | | | | | | | | | |0 | >> > * N1|3 | | | | | | | | | | | | | | | | >> > N2| |3 | | | | | | | | | | | | | | | >> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >> > N4| | |2 | | | | | | | | | | | | | | >> > N6| | | | | | |1 |1 | |1 | | | | | | | >> > N7| | | | | | | |4 | | | | | | | | | >> > N8| | | | | | | | | |3 |2 | | | | | | >> > N9| | | | | | | | |1 | |1 |1 | | | | | >> > N10| | | | | | | | | | | |2 | | | | | >> > N11| | | | | | | | |3 | | | | | | | | >> > N12| | | | |8 | |2 | | | | | | | | | | >> > N13| | | | |8 | | | | | | | | | | | | >> > N14| | | | |8 | | | | | | | | | | | | >> > N15| | | | | | |9 | | | | | | | | | | >> > H1| | | | | | | | | | | |10| | | | | >> > Ia| | | | | | | | | |5 | | | | | | | >> > Ib| | | | | |7 | | | | | | | | | | | >> > >> > Notes >> > ----- >> > section 2.1.2 >> > >> > Page 20, Figure 2 : A sample Autonomous System. >> > >> > The interfaces Ia and Ib have not been added to the directed graph. >> > By definition of point-to-point links under OSPF, for serial interfaces >> defined by IP addresses, >> > router RT6 should advertise a stub network to Ib whereas router RT6 >> should advertise a stub network to Ia . >> > >> > Instructions: >> > ------------- >> > This errata is currently posted as "Reported". If necessary, please >> > use "Reply All" to discuss whether it should be verified or >> > rejected. When a decision is reached, the verifying party (IESG) >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC2328 (no draft string recorded) >> > -------------------------------------- >> > Title : OSPF Version 2 >> > Publication Date : April 1998 >> > Author(s) : J. Moy >> > Category : INTERNET STANDARD >> > Source : Open Shortest Path First IGP >> > Area : Routing >> > Stream : IETF >> > Verifying Party : IESG >> > _______________________________________________ >> > OSPF mailing list >> > OSPF@ietf.org >> > https://www.ietf.org/mailman/listinfo/ospf >> >> > --047d7b5d8e79ca91d104de964ae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 =A0 The corrected text should be as under.=A0
=A0 =A0 The additions are = noted in bold.=A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0**FROM**

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ---= -- ---------------------------------------------
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 | =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0|= 0 | =A0| =A0| =A0|
=A0 =A0= =A0 =A0 =A0 =A0 =A0 RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| =A0|5 | =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|0 | =A0| =A0|
=A0 =A0= =A0 =A0 =A0 * =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0|
=A0 =A0 =A0 =A0= =A0 * =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0|0 |
=A0 =A0= =A0 =A0 =A0 T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0|0 |0 | =A0|
=A0 =A0 =A0 =A0= =A0 O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0|0 |0 |
=A0 =A0 = =A0 =A0 =A0 * =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |
=A0 =A0 =A0 =A0= =A0 * =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | =A0|1 | =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 |2 | =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1 | = =A0|1 |1 | =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|2 |= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 | =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1= 0| =A0| =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0|

On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza <= span dir=3D"ltr"><preet.desouza17@gmail.com> wrote:
Hello Acee,

<= div>I made two additions.=A0
The last two rows in the **To** colum= n have been added.
They are interfaces =A0Ia and =A0 Ib =A0which are represented as stub = networks owing to their definition on a point-to-point link between RT6 and= RT10


On Sat, Jun 8, 2013 at 1:29 AM= , Acee Lindem <acee@lindem.com> wrote:
Preet - Can you denote which boxes you chang= ed and why? In its current state, this errata should be summarily rejected.=
Thanks,
Acee
On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D2328&eid=3D3644
>
> --------------------------------------
> Type: Technical
> Reported by: Preet D'Souza <preet.desouza17@gmail.com>
>
> Section: 2.1.2
>
> Original Text
> -------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 **FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
>
>
> Corrected Text
> --------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0**FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
>
> Notes
> -----
> section 2.1.2
>
> Page 20, Figure 2 : A sample Autonomous System.
>
> The interfaces =A0 Ia =A0and Ib =A0have not been added to the directed= graph.
> By definition of point-to-point links under OSPF, for serial interface= s defined by IP addresses,
> router RT6 should advertise a stub network to Ib whereas router RT6 sh= ould advertise a stub network to Ia .
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : OSPF Version 2
> Publication Date =A0 =A0: April 1998
> Author(s) =A0 =A0 =A0 =A0 =A0 : J. Moy
> Category =A0 =A0 =A0 =A0 =A0 =A0: INTERNET STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf



--047d7b5d8e79ca91d104de964ae3-- From preet.desouza17@gmail.com Fri Jun 7 13:35:52 2013 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 38B2421F9956 for ; Fri, 7 Jun 2013 13:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, NO_RELAYS=-0.001] 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 gGxtYTarS4Cw for ; Fri, 7 Jun 2013 13:35:50 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7053921F98AD for ; Fri, 7 Jun 2013 13:35:50 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so1320508qab.12 for ; Fri, 07 Jun 2013 13:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WkWQ5KpniXrOfC23nSbNgKYhio1MaGBfXy7ZjssmJOI=; b=UtSHdbU12zPEJ7npSHpsisLI8BvsuCiyMcLiftnTDrFr6lQD8fkAGIIwbSbEs9XBup kCPlKBaSaV4rtxsNt9SO9znRpv5U8gxvBRvHSyGUa/KpUBKJ+nS9g4dRGIlD0ZeQNzDi MW64gXAHI/Ko8gbpuflBGjnPfUf9jJW9pjnMLnvVqmLPVkyoqze8qmwVO0C+sSVc8PcD qzCzszsPNLgInoPC+1oYr7OcrsG3mkM6xbF8RCXf3jmOafb/UirTz1prDreHEbzWbN9e 6g2kd053QMO1yH/HCPci45gZwHY8RAmrms9CrGyL/hPk3lWs6Zn2y7FaZWGWhuop7v7V Lx+w== MIME-Version: 1.0 X-Received: by 10.224.71.145 with SMTP id h17mr4974316qaj.31.1370637349900; Fri, 07 Jun 2013 13:35:49 -0700 (PDT) Received: by 10.224.74.2 with HTTP; Fri, 7 Jun 2013 13:35:49 -0700 (PDT) In-Reply-To: References: <20130607194649.DFE7B62114@rfc-editor.org> Date: Sat, 8 Jun 2013 02:05:49 +0530 Message-ID: From: Preet DSouza To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7bea31745b5c4e04de96601d Cc: jmoy@casc.com, RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Fri, 07 Jun 2013 20:35:52 -0000 --047d7bea31745b5c4e04de96601d Content-Type: text/plain; charset=ISO-8859-1 Kindly note that I've made a minor mistake in the RFC errata notes. It says, Notes: section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. The interfaces Ia and Ib have not been added to the directed graph. By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT6 should advertise a stub network to Ia . It should say, Notes: section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. The interfaces Ia and Ib have not been added to the directed graph. By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router *RT10*should advertise a stub network to Ia . On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza wrote: > The corrected text should be as under. > The additions are noted in bold. > > **FROM** > > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| > ----- --------------------------------------------- > RT1| | | | | | | | | | | | |0 | | | | > RT2| | | | | | | | | | | | |0 | | | | > RT3| | | | | |6 | | | | | | |0 | | | | > RT4| | | | |8 | | | | | | | |0 | | | | > RT5| | | |8 | |6 |6 | | | | | | | | | | > RT6| | |8 | |7 | | | | |5 | | | | | | | > RT7| | | | |6 | | | | | | | | |0 | | | > * RT8| | | | | | | | | | | | | |0 | | | > * RT9| | | | | | | | | | | | | | | |0 | > T RT10| | | | | |7 | | | | | | | |0 |0 | | > O RT11| | | | | | | | | | | | | | |0 |0 | > * RT12| | | | | | | | | | | | | | | |0 | > * N1|3 | | | | | | | | | | | | | | | | > N2| |3 | | | | | | | | | | | | | | | > N3|1 |1 |1 |1 | | | | | | | | | | | | | > N4| | |2 | | | | | | | | | | | | | | > N6| | | | | | |1 |1 | |1 | | | | | | | > N7| | | | | | | |4 | | | | | | | | | > N8| | | | | | | | | |3 |2 | | | | | | > N9| | | | | | | | |1 | |1 |1 | | | | | > N10| | | | | | | | | | | |2 | | | | | > N11| | | | | | | | |3 | | | | | | | | > N12| | | | |8 | |2 | | | | | | | | | | > N13| | | | |8 | | | | | | | | | | | | > N14| | | | |8 | | | | | | | | | | | | > N15| | | | | | |9 | | | | | | | | | | > H1| | | | | | | | | | | |10| | | | | > *Ia| | | | | | | | | |5 | | | | | | |** > Ib| | | | | |7 | | | | | | | | | | |* > > > On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza wrote: > >> Hello Acee, >> >> I made two additions. >> The last two rows in the **To** column have been added. >> They are interfaces Ia and Ib which are represented as stub networks >> owing to their definition on a point-to-point link between RT6 and RT10 >> >> >> On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem wrote: >> >>> Preet - Can you denote which boxes you changed and why? In its current >>> state, this errata should be summarily rejected. >>> Thanks, >>> Acee >>> On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: >>> >>> > The following errata report has been submitted for RFC2328, >>> > "OSPF Version 2". >>> > >>> > -------------------------------------- >>> > You may review the report below and at: >>> > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3644 >>> > >>> > -------------------------------------- >>> > Type: Technical >>> > Reported by: Preet D'Souza >>> > >>> > Section: 2.1.2 >>> > >>> > Original Text >>> > ------------- >>> > **FROM** >>> > >>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>> > ----- --------------------------------------------- >>> > RT1| | | | | | | | | | | | |0 | | | | >>> > RT2| | | | | | | | | | | | |0 | | | | >>> > RT3| | | | | |6 | | | | | | |0 | | | | >>> > RT4| | | | |8 | | | | | | | |0 | | | | >>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>> > RT7| | | | |6 | | | | | | | | |0 | | | >>> > * RT8| | | | | | | | | | | | | |0 | | | >>> > * RT9| | | | | | | | | | | | | | | |0 | >>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>> > * RT12| | | | | | | | | | | | | | | |0 | >>> > * N1|3 | | | | | | | | | | | | | | | | >>> > N2| |3 | | | | | | | | | | | | | | | >>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>> > N4| | |2 | | | | | | | | | | | | | | >>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>> > N7| | | | | | | |4 | | | | | | | | | >>> > N8| | | | | | | | | |3 |2 | | | | | | >>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>> > N10| | | | | | | | | | | |2 | | | | | >>> > N11| | | | | | | | |3 | | | | | | | | >>> > N12| | | | |8 | |2 | | | | | | | | | | >>> > N13| | | | |8 | | | | | | | | | | | | >>> > N14| | | | |8 | | | | | | | | | | | | >>> > N15| | | | | | |9 | | | | | | | | | | >>> > H1| | | | | | | | | | | |10| | | | | >>> > >>> > >>> > Corrected Text >>> > -------------- >>> > **FROM** >>> > >>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>> > ----- --------------------------------------------- >>> > RT1| | | | | | | | | | | | |0 | | | | >>> > RT2| | | | | | | | | | | | |0 | | | | >>> > RT3| | | | | |6 | | | | | | |0 | | | | >>> > RT4| | | | |8 | | | | | | | |0 | | | | >>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>> > RT7| | | | |6 | | | | | | | | |0 | | | >>> > * RT8| | | | | | | | | | | | | |0 | | | >>> > * RT9| | | | | | | | | | | | | | | |0 | >>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>> > * RT12| | | | | | | | | | | | | | | |0 | >>> > * N1|3 | | | | | | | | | | | | | | | | >>> > N2| |3 | | | | | | | | | | | | | | | >>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>> > N4| | |2 | | | | | | | | | | | | | | >>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>> > N7| | | | | | | |4 | | | | | | | | | >>> > N8| | | | | | | | | |3 |2 | | | | | | >>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>> > N10| | | | | | | | | | | |2 | | | | | >>> > N11| | | | | | | | |3 | | | | | | | | >>> > N12| | | | |8 | |2 | | | | | | | | | | >>> > N13| | | | |8 | | | | | | | | | | | | >>> > N14| | | | |8 | | | | | | | | | | | | >>> > N15| | | | | | |9 | | | | | | | | | | >>> > H1| | | | | | | | | | | |10| | | | | >>> > Ia| | | | | | | | | |5 | | | | | | | >>> > Ib| | | | | |7 | | | | | | | | | | | >>> > >>> > Notes >>> > ----- >>> > section 2.1.2 >>> > >>> > Page 20, Figure 2 : A sample Autonomous System. >>> > >>> > The interfaces Ia and Ib have not been added to the directed graph. >>> > By definition of point-to-point links under OSPF, for serial >>> interfaces defined by IP addresses, >>> > router RT6 should advertise a stub network to Ib whereas router RT6 >>> should advertise a stub network to Ia . >>> > >>> > Instructions: >>> > ------------- >>> > This errata is currently posted as "Reported". If necessary, please >>> > use "Reply All" to discuss whether it should be verified or >>> > rejected. When a decision is reached, the verifying party (IESG) >>> > can log in to change the status and edit the report, if necessary. >>> > >>> > -------------------------------------- >>> > RFC2328 (no draft string recorded) >>> > -------------------------------------- >>> > Title : OSPF Version 2 >>> > Publication Date : April 1998 >>> > Author(s) : J. Moy >>> > Category : INTERNET STANDARD >>> > Source : Open Shortest Path First IGP >>> > Area : Routing >>> > Stream : IETF >>> > Verifying Party : IESG >>> > _______________________________________________ >>> > OSPF mailing list >>> > OSPF@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ospf >>> >>> >> > --047d7bea31745b5c4e04de96601d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kindly note that I've made a minor mistake in the RFC = errata notes.

It says,

<= div style>

Notes:

section 2.1.2

Page 20, = Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have= not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses,
router RT6 should advertise a stub network to Ib w= hereas router RT6 should advertise a stub network to Ia .


It should say,

Notes:

section 2.1.2

Page 20, Figu= re 2 : A sample Autonomous System.

The inter= faces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial int= erfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whereas r= outer RT10 should ad= vertise a stub network to Ia .


<= div class=3D"gmail_extra">

On Sat, Jun 8, 2013 at 1:59 AM, Preet DS= ouza <preet.desouza17@gmail.com> wrote:
=A0 =A0 The corrected text should be as under.=A0
=A0 =A0 The additions are = noted in bold.=A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0**FROM**

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ---= -- ---------------------------------------------
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 | =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0|= 0 | =A0| =A0| =A0|
=A0 =A0= =A0 =A0 =A0 =A0 =A0 RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| =A0|5 | =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|0 | =A0| =A0|
=A0 =A0= =A0 =A0 =A0 * =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0|
=A0 =A0 =A0 =A0= =A0 * =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0|0 |
=A0 =A0= =A0 =A0 =A0 T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0|0 |0 | =A0|
=A0 =A0 =A0 =A0= =A0 O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0|0 |0 |
=A0 =A0 = =A0 =A0 =A0 * =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |
=A0 =A0 =A0 =A0= =A0 * =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | =A0|1 | =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 |2 | =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1 | = =A0|1 |1 | =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|2 |= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 | =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1= 0| =A0| =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0|


On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza <preet.desouza17@gmail.com> wrote:
Hello Acee,

<= div>I made two additions.=A0
The last two rows in the **To** colum= n have been added.
They are interfaces =A0Ia and =A0 Ib =A0which are represented as stub = networks owing to their definition on a point-to-point link between RT6 and= RT10


On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem <acee@lindem.co= m> wrote:
Preet - Can you denote which boxes you chang= ed and why? In its current state, this errata should be summarily rejected.=
Thanks,
Acee
On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D2328&eid=3D3644
>
> --------------------------------------
> Type: Technical
> Reported by: Preet D'Souza <preet.desouza17@gmail.com>
>
> Section: 2.1.2
>
> Original Text
> -------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 **FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
>
>
> Corrected Text
> --------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0**FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
>
> Notes
> -----
> section 2.1.2
>
> Page 20, Figure 2 : A sample Autonomous System.
>
> The interfaces =A0 Ia =A0and Ib =A0have not been added to the directed= graph.
> By definition of point-to-point links under OSPF, for serial interface= s defined by IP addresses,
> router RT6 should advertise a stub network to Ib whereas router RT6 sh= ould advertise a stub network to Ia .
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : OSPF Version 2
> Publication Date =A0 =A0: April 1998
> Author(s) =A0 =A0 =A0 =A0 =A0 : J. Moy
> Category =A0 =A0 =A0 =A0 =A0 =A0: INTERNET STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf




--047d7bea31745b5c4e04de96601d-- From wwwrun@rfc-editor.org Fri Jun 7 13:48:30 2013 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 5572521F999E for ; Fri, 7 Jun 2013 13:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.292 X-Spam-Level: X-Spam-Status: No, score=-101.292 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_00=-2.599, MANGLED_NAIL=2.3, NO_RELAYS=-0.001, 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 8NS+fwWZBS0D for ; Fri, 7 Jun 2013 13:48:29 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAF321F99AA for ; Fri, 7 Jun 2013 13:48:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BAC2262114; Fri, 7 Jun 2013 13:46:58 -0700 (PDT) To: jmoy@casc.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130607204658.BAC2262114@rfc-editor.org> Date: Fri, 7 Jun 2013 13:46:58 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC2328 (3645) 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: Fri, 07 Jun 2013 20:48:30 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3645 -------------------------------------- Type: Technical Reported by: Preet D'Souza Section: 2.1.2 Original Text ------------- Figure 2: A sample Autonomous System **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Corrected Text -------------- Figure 2: A sample Autonomous System **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Ia| | | | | | | | | |5 | | | | | | | Ib| | | | | |7 | | | | | | | | | | | Notes ----- Notes: section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. Two additions have been made to the orginal text which are reflected in the Corrected text. The last two rows for interfaces Ia and Ib have been added. The reason for the same is as explained below. By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT10 should advertise a stub network to Ia . Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From preet.desouza17@gmail.com Fri Jun 7 13:49:49 2013 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 1D3D521F99A7 for ; Fri, 7 Jun 2013 13:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, NO_RELAYS=-0.001] 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 bPPQ91gCRjBS for ; Fri, 7 Jun 2013 13:49:47 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 88ADF21F99A1 for ; Fri, 7 Jun 2013 13:49:47 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so1192132qak.14 for ; Fri, 07 Jun 2013 13:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hf4Jfmbc9fVa6YvCq+VmHSmVdGxKGY1YqJ64RzO2BRs=; b=RyaIKhiYzQC8uOLdfygzjE3MebzpBKNYcUIRf7kPRXTO8aSQUYQbWk1zfnoxMmPSzd S/XCsgaqRSA7t28iFciLaibinnjTwHxbK9aTYy+biOfFNF6Kjqj/v2+tCIzJshhPw2UX vMNt+1wfvs9bD0szbGb1ozuOVqgjV8nppoqxlIZAlxc+TXrD/oiwVU8JtEEWxWshGGJp kUs+vGT6idd2/LGa0JOoinJD1p9rufdjYyuic9cudBFgZn4lRSU6tO2XjT5ovBPWL7bj kfpJ2g4IFah9k0wLMIuGoMyZu6SQye0lMdjGom4jFtkkP6NbT6i9Kh5+lfWWpbJBkYUp Qg8w== MIME-Version: 1.0 X-Received: by 10.49.24.198 with SMTP id w6mr437581qef.58.1370638186904; Fri, 07 Jun 2013 13:49:46 -0700 (PDT) Received: by 10.224.74.2 with HTTP; Fri, 7 Jun 2013 13:49:46 -0700 (PDT) In-Reply-To: References: <20130607194649.DFE7B62114@rfc-editor.org> Date: Sat, 8 Jun 2013 02:19:46 +0530 Message-ID: From: Preet DSouza To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b5d8e793f056c04de969285 Cc: jmoy@casc.com, RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Fri, 07 Jun 2013 20:49:49 -0000 --047d7b5d8e793f056c04de969285 Content-Type: text/plain; charset=ISO-8859-1 Please refer to RFC errata ID 3645 for the corrected report which has been submitted. On Sat, Jun 8, 2013 at 2:05 AM, Preet DSouza wrote: > Kindly note that I've made a minor mistake in the RFC errata notes. > > It says, > > Notes: > > section 2.1.2 > > Page 20, Figure 2 : A sample Autonomous System. > > The interfaces Ia and Ib have not been added to the directed graph. > By definition of point-to-point links under OSPF, for serial interfaces > defined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router RT6 should > advertise a stub network to Ia . > > > It should say, > > Notes: > > section 2.1.2 > > Page 20, Figure 2 : A sample Autonomous System. > > The interfaces Ia and Ib have not been added to the directed graph. > By definition of point-to-point links under OSPF, for serial interfaces > defined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router *RT10*should advertise a stub network to Ia . > > > > > On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza wrote: > >> The corrected text should be as under. >> The additions are noted in bold. >> >> **FROM** >> >> |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >> |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >> ----- --------------------------------------------- >> RT1| | | | | | | | | | | | |0 | | | | >> RT2| | | | | | | | | | | | |0 | | | | >> RT3| | | | | |6 | | | | | | |0 | | | | >> RT4| | | | |8 | | | | | | | |0 | | | | >> RT5| | | |8 | |6 |6 | | | | | | | | | | >> RT6| | |8 | |7 | | | | |5 | | | | | | | >> RT7| | | | |6 | | | | | | | | |0 | | | >> * RT8| | | | | | | | | | | | | |0 | | | >> * RT9| | | | | | | | | | | | | | | |0 | >> T RT10| | | | | |7 | | | | | | | |0 |0 | | >> O RT11| | | | | | | | | | | | | | |0 |0 | >> * RT12| | | | | | | | | | | | | | | |0 | >> * N1|3 | | | | | | | | | | | | | | | | >> N2| |3 | | | | | | | | | | | | | | | >> N3|1 |1 |1 |1 | | | | | | | | | | | | | >> N4| | |2 | | | | | | | | | | | | | | >> N6| | | | | | |1 |1 | |1 | | | | | | | >> N7| | | | | | | |4 | | | | | | | | | >> N8| | | | | | | | | |3 |2 | | | | | | >> N9| | | | | | | | |1 | |1 |1 | | | | | >> N10| | | | | | | | | | | |2 | | | | | >> N11| | | | | | | | |3 | | | | | | | | >> N12| | | | |8 | |2 | | | | | | | | | | >> N13| | | | |8 | | | | | | | | | | | | >> N14| | | | |8 | | | | | | | | | | | | >> N15| | | | | | |9 | | | | | | | | | | >> H1| | | | | | | | | | | |10| | | | | >> *Ia| | | | | | | | | |5 | | | | | | |** >> Ib| | | | | |7 | | | | | | | | | | |* >> >> >> On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza wrote: >> >>> Hello Acee, >>> >>> I made two additions. >>> The last two rows in the **To** column have been added. >>> They are interfaces Ia and Ib which are represented as stub networks >>> owing to their definition on a point-to-point link between RT6 and RT10 >>> >>> >>> On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem wrote: >>> >>>> Preet - Can you denote which boxes you changed and why? In its current >>>> state, this errata should be summarily rejected. >>>> Thanks, >>>> Acee >>>> On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: >>>> >>>> > The following errata report has been submitted for RFC2328, >>>> > "OSPF Version 2". >>>> > >>>> > -------------------------------------- >>>> > You may review the report below and at: >>>> > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3644 >>>> > >>>> > -------------------------------------- >>>> > Type: Technical >>>> > Reported by: Preet D'Souza >>>> > >>>> > Section: 2.1.2 >>>> > >>>> > Original Text >>>> > ------------- >>>> > **FROM** >>>> > >>>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>>> > ----- --------------------------------------------- >>>> > RT1| | | | | | | | | | | | |0 | | | | >>>> > RT2| | | | | | | | | | | | |0 | | | | >>>> > RT3| | | | | |6 | | | | | | |0 | | | | >>>> > RT4| | | | |8 | | | | | | | |0 | | | | >>>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>>> > RT7| | | | |6 | | | | | | | | |0 | | | >>>> > * RT8| | | | | | | | | | | | | |0 | | | >>>> > * RT9| | | | | | | | | | | | | | | |0 | >>>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>>> > * RT12| | | | | | | | | | | | | | | |0 | >>>> > * N1|3 | | | | | | | | | | | | | | | | >>>> > N2| |3 | | | | | | | | | | | | | | | >>>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>>> > N4| | |2 | | | | | | | | | | | | | | >>>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>>> > N7| | | | | | | |4 | | | | | | | | | >>>> > N8| | | | | | | | | |3 |2 | | | | | | >>>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>>> > N10| | | | | | | | | | | |2 | | | | | >>>> > N11| | | | | | | | |3 | | | | | | | | >>>> > N12| | | | |8 | |2 | | | | | | | | | | >>>> > N13| | | | |8 | | | | | | | | | | | | >>>> > N14| | | | |8 | | | | | | | | | | | | >>>> > N15| | | | | | |9 | | | | | | | | | | >>>> > H1| | | | | | | | | | | |10| | | | | >>>> > >>>> > >>>> > Corrected Text >>>> > -------------- >>>> > **FROM** >>>> > >>>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>>> > ----- --------------------------------------------- >>>> > RT1| | | | | | | | | | | | |0 | | | | >>>> > RT2| | | | | | | | | | | | |0 | | | | >>>> > RT3| | | | | |6 | | | | | | |0 | | | | >>>> > RT4| | | | |8 | | | | | | | |0 | | | | >>>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>>> > RT7| | | | |6 | | | | | | | | |0 | | | >>>> > * RT8| | | | | | | | | | | | | |0 | | | >>>> > * RT9| | | | | | | | | | | | | | | |0 | >>>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>>> > * RT12| | | | | | | | | | | | | | | |0 | >>>> > * N1|3 | | | | | | | | | | | | | | | | >>>> > N2| |3 | | | | | | | | | | | | | | | >>>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>>> > N4| | |2 | | | | | | | | | | | | | | >>>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>>> > N7| | | | | | | |4 | | | | | | | | | >>>> > N8| | | | | | | | | |3 |2 | | | | | | >>>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>>> > N10| | | | | | | | | | | |2 | | | | | >>>> > N11| | | | | | | | |3 | | | | | | | | >>>> > N12| | | | |8 | |2 | | | | | | | | | | >>>> > N13| | | | |8 | | | | | | | | | | | | >>>> > N14| | | | |8 | | | | | | | | | | | | >>>> > N15| | | | | | |9 | | | | | | | | | | >>>> > H1| | | | | | | | | | | |10| | | | | >>>> > Ia| | | | | | | | | |5 | | | | | | | >>>> > Ib| | | | | |7 | | | | | | | | | | | >>>> > >>>> > Notes >>>> > ----- >>>> > section 2.1.2 >>>> > >>>> > Page 20, Figure 2 : A sample Autonomous System. >>>> > >>>> > The interfaces Ia and Ib have not been added to the directed >>>> graph. >>>> > By definition of point-to-point links under OSPF, for serial >>>> interfaces defined by IP addresses, >>>> > router RT6 should advertise a stub network to Ib whereas router RT6 >>>> should advertise a stub network to Ia . >>>> > >>>> > Instructions: >>>> > ------------- >>>> > This errata is currently posted as "Reported". If necessary, please >>>> > use "Reply All" to discuss whether it should be verified or >>>> > rejected. When a decision is reached, the verifying party (IESG) >>>> > can log in to change the status and edit the report, if necessary. >>>> > >>>> > -------------------------------------- >>>> > RFC2328 (no draft string recorded) >>>> > -------------------------------------- >>>> > Title : OSPF Version 2 >>>> > Publication Date : April 1998 >>>> > Author(s) : J. Moy >>>> > Category : INTERNET STANDARD >>>> > Source : Open Shortest Path First IGP >>>> > Area : Routing >>>> > Stream : IETF >>>> > Verifying Party : IESG >>>> > _______________________________________________ >>>> > OSPF mailing list >>>> > OSPF@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> >>> >> > --047d7b5d8e793f056c04de969285 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please refer to RFC errata ID 3645 for the corrected repor= t which has been submitted.=A0


On Sat, Jun 8, 2013 at 2:05 AM, Preet DSouza <preet.desouza17@gmail.com> wrote:
Kindly note that I've m= ade a minor mistake in the RFC errata notes.

It says,

Notes:

section 2.1.2

Page 20, Figure 2 := A sample Autonomous System.

The interfaces Ia and Ib have not been = added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses,
router RT6 should advertise a stub network to Ib w= hereas router RT6 should advertise a stub network to Ia .


It should say,

Notes:

section 2.1.2

Page 20, Figu= re 2 : A sample Autonomous System.

The inter= faces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial int= erfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whe= reas router RT10 sho= uld advertise a stub network to Ia .




On Sat, Jun 8, 2013 at 1:59 AM, Preet DS= ouza <preet.desouza17@gmail.com> wrote:
=A0 =A0 The corrected text should be as under.=A0
=A0 =A0 The additions are = noted in bold.=A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0**FROM**

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ---= -- ---------------------------------------------
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 | =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0|= 0 | =A0| =A0| =A0|
=A0 =A0= =A0 =A0 =A0 =A0 =A0 RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| =A0|5 | =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|0 | =A0| =A0|
=A0 =A0= =A0 =A0 =A0 * =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0|0 | =A0| =A0|
=A0 =A0 =A0 =A0= =A0 * =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0|0 |
=A0 =A0= =A0 =A0 =A0 T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0|0 |0 | =A0|
=A0 =A0 =A0 =A0= =A0 O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0|0 |0 |
=A0 =A0 = =A0 =A0 =A0 * =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |
=A0 =A0 =A0 =A0= =A0 * =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | =A0|1 | =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 |2 | =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1 | = =A0|1 |1 | =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|2 |= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 | =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| =A0| =A0= | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1= 0| =A0| =A0| =A0| =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0|


On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza <preet.desouza17@gmail.com> wrote:
Hello Acee,

<= div>I made two additions.=A0
The last two rows in the **To** colum= n have been added.
They are interfaces =A0Ia and =A0 Ib =A0which are represented as stub = networks owing to their definition on a point-to-point link between RT6 and= RT10


On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem <acee@lindem.co= m> wrote:
Preet - Can you denote which boxes you chang= ed and why? In its current state, this errata should be summarily rejected.=
Thanks,
Acee
On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D2328&eid=3D3644
>
> --------------------------------------
> Type: Technical
> Reported by: Preet D'Souza <preet.desouza17@gmail.com>
>
> Section: 2.1.2
>
> Original Text
> -------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 **FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
>
>
> Corrected Text
> --------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0**FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
>
> Notes
> -----
> section 2.1.2
>
> Page 20, Figure 2 : A sample Autonomous System.
>
> The interfaces =A0 Ia =A0and Ib =A0have not been added to the directed= graph.
> By definition of point-to-point links under OSPF, for serial interface= s defined by IP addresses,
> router RT6 should advertise a stub network to Ib whereas router RT6 sh= ould advertise a stub network to Ia .
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : OSPF Version 2
> Publication Date =A0 =A0: April 1998
> Author(s) =A0 =A0 =A0 =A0 =A0 : J. Moy
> Category =A0 =A0 =A0 =A0 =A0 =A0: INTERNET STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf





--047d7b5d8e793f056c04de969285-- From prvs=38714c032d=acee.lindem@ericsson.com Fri Jun 7 20:45:46 2013 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 0C58611E80A3 for ; Fri, 7 Jun 2013 20:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3] 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 Q+IaHWQq4ceU for ; Fri, 7 Jun 2013 20:45:40 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE711E80A5 for ; Fri, 7 Jun 2013 20:45:40 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-79-51b2a8da03b8 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 29.01.05617.AD8A2B15; Sat, 8 Jun 2013 05:45:30 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 23:45:29 -0400 From: Acee Lindem To: Preet DSouza Thread-Topic: [OSPF] [Technical Errata Reported] RFC2328 (3644) Thread-Index: AQHOY7f6qPhyD2LpzUW3CpH5q4igrJkq7r+AgAAEDYCAAARUAIAAAa6AgAB4CQA= Date: Sat, 8 Jun 2013 03:45:29 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715F7DF@eusaamb101.ericsson.se> References: <20130607194649.DFE7B62114@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4715F7DFeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXRPiO6tFZsCDda8kLeYdms6m8WPnhvM FocPzmKzmDhXxqLl3j12i1dtjxktmvZ/ZbM493QOowOHx7/V25g9pvzeyOqxc9Zddo8lS34y eXxYdIHVY8XmlYweDW3HWAPYo7htkhJLyoIz0/P07RK4M9bd38te8GUXU8Xu6x+YGxhbvzB2 MXJySAiYSDzt6mGHsMUkLtxbz9bFyMUhJHCUUWL2tT2sEM4yRolff26yglSxCehIPH/0jxnE FgGyd2z+BzaJWaCVSeLzOk0QW1jATuLtg90sEDX2Eg+3f2KEsP0knhw9DTaHRUBF4uXuDWA2 r4C3xJHTU6CW7WeSePdpBdhJnAKBEh1tO8EGMQKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zzBC2 qMTLx/9YIWxlie9zHrFA1OdLnJx5ng1imSCQ/YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj6F6rSUWLfvAjqxmASPHKkaO0uLUstx0I8NNjMAYPybB5riDccEny0OM0hws SuK8OryLA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwggguqQbGyEtzys1Da2b87zCVTU8LWXMt Mmzul6WTzsqVlEl/sv149JnL+lXxn6KDTsYvYJfbdsF7ZfSP7Q/bxP50PlKsmuu41+vi+Sfu Ty9G/xPp/PzRPGmn8NIXv0/MV7tdeCQ1RUesPjz8ycfrkvMYVXbPmC29bq/311DZjN6FDG7z vE5pcLL+21Q4SYmlOCPRUIu5qDgRAEhV9vTEAgAA Cc: "" , RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Sat, 08 Jun 2013 03:45:46 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4715F7DFeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Preet, Figure 3 contains "The resulting directed graph". Since Ia and Ib are simpl= y the endpoints of a point-to-point network, they do not represent vertexes= in the directed graph and need not be included in figure 3. A point-to-poi= nt link is imply an edge in the graph. My recommendation is that your errat= a be rejected. Thanks, Acee On Jun 7, 2013, at 4:35 PM, Preet DSouza wrote: Kindly note that I've made a minor mistake in the RFC errata notes. It says, Notes: section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. The interfaces Ia and Ib have not been added to the directed graph. By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT6 should = advertise a stub network to Ia . It should say, Notes: section 2.1.2 Page 20, Figure 2 : A sample Autonomous System. The interfaces Ia and Ib have not been added to the directed graph. By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT10 should= advertise a stub network to Ia . On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza > wrote: The corrected text should be as under. The additions are noted in bold. **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Ia| | | | | | | | | |5 | | | | | | | Ib| | | | | |7 | | | | | | | | | | | On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza > wrote: Hello Acee, I made two additions. The last two rows in the **To** column have been added. They are interfaces Ia and Ib which are represented as stub networks ow= ing to their definition on a point-to-point link between RT6 and RT10 On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem > wrote: Preet - Can you denote which boxes you changed and why? In its current stat= e, this errata should be summarily rejected. Thanks, Acee On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3644 > > -------------------------------------- > Type: Technical > Reported by: Preet D'Souza > > > Section: 2.1.2 > > Original Text > ------------- > **FROM** > > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| > ----- --------------------------------------------- > RT1| | | | | | | | | | | | |0 | | | | > RT2| | | | | | | | | | | | |0 | | | | > RT3| | | | | |6 | | | | | | |0 | | | | > RT4| | | | |8 | | | | | | | |0 | | | | > RT5| | | |8 | |6 |6 | | | | | | | | | | > RT6| | |8 | |7 | | | | |5 | | | | | | | > RT7| | | | |6 | | | | | | | | |0 | | | > * RT8| | | | | | | | | | | | | |0 | | | > * RT9| | | | | | | | | | | | | | | |0 | > T RT10| | | | | |7 | | | | | | | |0 |0 | | > O RT11| | | | | | | | | | | | | | |0 |0 | > * RT12| | | | | | | | | | | | | | | |0 | > * N1|3 | | | | | | | | | | | | | | | | > N2| |3 | | | | | | | | | | | | | | | > N3|1 |1 |1 |1 | | | | | | | | | | | | | > N4| | |2 | | | | | | | | | | | | | | > N6| | | | | | |1 |1 | |1 | | | | | | | > N7| | | | | | | |4 | | | | | | | | | > N8| | | | | | | | | |3 |2 | | | | | | > N9| | | | | | | | |1 | |1 |1 | | | | | > N10| | | | | | | | | | | |2 | | | | | > N11| | | | | | | | |3 | | | | | | | | > N12| | | | |8 | |2 | | | | | | | | | | > N13| | | | |8 | | | | | | | | | | | | > N14| | | | |8 | | | | | | | | | | | | > N15| | | | | | |9 | | | | | | | | | | > H1| | | | | | | | | | | |10| | | | | > > > Corrected Text > -------------- > **FROM** > > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| > ----- --------------------------------------------- > RT1| | | | | | | | | | | | |0 | | | | > RT2| | | | | | | | | | | | |0 | | | | > RT3| | | | | |6 | | | | | | |0 | | | | > RT4| | | | |8 | | | | | | | |0 | | | | > RT5| | | |8 | |6 |6 | | | | | | | | | | > RT6| | |8 | |7 | | | | |5 | | | | | | | > RT7| | | | |6 | | | | | | | | |0 | | | > * RT8| | | | | | | | | | | | | |0 | | | > * RT9| | | | | | | | | | | | | | | |0 | > T RT10| | | | | |7 | | | | | | | |0 |0 | | > O RT11| | | | | | | | | | | | | | |0 |0 | > * RT12| | | | | | | | | | | | | | | |0 | > * N1|3 | | | | | | | | | | | | | | | | > N2| |3 | | | | | | | | | | | | | | | > N3|1 |1 |1 |1 | | | | | | | | | | | | | > N4| | |2 | | | | | | | | | | | | | | > N6| | | | | | |1 |1 | |1 | | | | | | | > N7| | | | | | | |4 | | | | | | | | | > N8| | | | | | | | | |3 |2 | | | | | | > N9| | | | | | | | |1 | |1 |1 | | | | | > N10| | | | | | | | | | | |2 | | | | | > N11| | | | | | | | |3 | | | | | | | | > N12| | | | |8 | |2 | | | | | | | | | | > N13| | | | |8 | | | | | | | | | | | | > N14| | | | |8 | | | | | | | | | | | | > N15| | | | | | |9 | | | | | | | | | | > H1| | | | | | | | | | | |10| | | | | > Ia| | | | | | | | | |5 | | | | | | | > Ib| | | | | |7 | | | | | | | | | | | > > Notes > ----- > section 2.1.2 > > Page 20, Figure 2 : A sample Autonomous System. > > The interfaces Ia and Ib have not been added to the directed graph. > By definition of point-to-point links under OSPF, for serial interfaces d= efined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router RT6 shoul= d advertise a stub network to Ia . > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --_000_94A203EA12AECE4BA92D42DBFFE0AE4715F7DFeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <2F2898C0EABC0E48BE0783FAEEC8B7AB@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi Preet,
Figure 3 contains "The resulting directed graph". Since Ia a= nd Ib are simply the endpoints of a point-to-point network, they do not rep= resent vertexes in the directed graph and need not be included in figure 3.= A point-to-point link is imply an edge in the graph. My recommendation is that your errata be rejected. 
Thanks,
Acee
On Jun 7, 2013, at 4:35 PM, Preet DSouza wrote:

Kindly note that I've made a minor mistake in the RFC erra= ta notes.

It says,

= Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses,
router RT6 should advertise a stub network to Ib whereas router RT6 should = advertise a stub network to Ia .


It should say,

= Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the direct= ed graph.
By definition of point-to-point links under OSPF, for seri= al interfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whereas r= outer RT10 should advertise a stu= b network to Ia .




On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza <preet.de= souza17@gmail.com> wrote:
    The corrected text should be as under. 
  &nb= sp; The additions are noted in bold. 
  &nb= sp;                     &= nbsp; 
  &nb= sp;                     &= nbsp;          **FROM**

    &= nbsp;            |RT|RT|RT|RT|RT|RT|RT|RT|RT|= RT|RT|RT= |
    &= nbsp;            |1 |2 |3 |4 |5 |6 |7 |8 |9 |= 10|11|12|N3|N6|N8|N9|
    &= nbsp;         ----- -------------------------------------------= --
    &= nbsp;         RT1|  |  |  |  | &nbs= p;|  |  |  |  |  |  |  |0 |  | &nbs= p;|  |
    &= nbsp;         RT2|  |  |  |  | &nbs= p;|  |  |  |  |  |  |  |0 |  | &nbs= p;|  |
    &= nbsp;         RT3|  |  |  |  | &nbs= p;|6 |  |  |  |  |  |  |0 |  |  | &= nbsp;|
    &= nbsp;         RT4|  |  |  |  |8 | &= nbsp;|  |  |  |  |  |  |0 |  |  | &= nbsp;|
    &= nbsp;         RT5|  |  |  |8 |  |6 = |6 |  |  |  |  |  |  |  |  |  = |
    &= nbsp;         RT6|  |  |8 |  |7 |  = |  |  |  |5 |  |  |  |  |  |  = |
    &= nbsp;         RT7|  |  |  |  |6 | &= nbsp;|  |  |  |  |  |  |  |0 |  | &= nbsp;|
    &= nbsp;     *   RT8|  |  |  |  |  | &= nbsp;|  |  |  |  |  |  |  |0 |  | &= nbsp;|
    &= nbsp;     *   RT9|  |  |  |  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |
    &= nbsp;     T  RT10|  |  |  |  |  |7 = |  |  |  |  |  |  |  |0 |0 |  |
    &= nbsp;     O  RT11|  |  |  |  |  | &= nbsp;|  |  |  |  |  |  |  |  |0 |0 = |
    &= nbsp;     *  RT12|  |  |  |  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |
    &= nbsp;     *    N1|3 |  |  |  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|  |
    &= nbsp;          N2|  |3 |  |  | &nbs= p;|  |  |  |  |  |  |  |  |  |=  |  |
    &= nbsp;          N3|1 |1 |1 |1 |  |  | &nb= sp;|  |  |  |  |  |  |  |  |  = |
    &= nbsp;          N4|  |  |2 |  | &nbs= p;|  |  |  |  |  |  |  |  |  |=  |  |
    &= nbsp;          N6|  |  |  |  |=  |  |1 |1 |  |1 |  |  |  |  |  | &= nbsp;|
    &= nbsp;          N7|  |  |  |  |=  |  |  |4 |  |  |  |  |  |  |=  |  |
    &= nbsp;          N8|  |  |  |  |=  |  |  |  |  |3 |2 |  |  |  | &nbs= p;|  |
    &= nbsp;          N9|  |  |  |  |=  |  |  |  |1 |  |1 |1 |  |  |  | &= nbsp;|
    &= nbsp;         N10|  |  |  |  | &nbs= p;|  |  |  |  |  |  |2 |  |  | &nbs= p;|  |
    &= nbsp;         N11|  |  |  |  | &nbs= p;|  |  |  |3 |  |  |  |  |  | &nbs= p;|  |
    &= nbsp;         N12|  |  |  |  |8 | &= nbsp;|2 |  |  |  |  |  |  |  |  | &= nbsp;|
    &= nbsp;         N13|  |  |  |  |8 | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|  |
    &= nbsp;         N14|  |  |  |  |8 | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|  |
    &= nbsp;         N15|  |  |  |  | &nbs= p;|  |9 |  |  |  |  |  |  |  | &nbs= p;|  |
    &= nbsp;          H1|  |  |  |  |=  |  |  |  |  |  |  |10|  |  |=  |  |
    &= nbsp;          Ia|  |  |  | &nb= sp;|  |  |  |  |  |5 |  |  |  | &nb= sp;|  |  |
        &n= bsp;      Ib|  |  |  |  |  |7 | &nb= sp;|  |  |  |  |  |  |  |  |  = |


On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza <preet.de= souza17@gmail.com> wrote:
Hello Acee,

I made two additions. 
The last two rows in the **To** column have been added.
They are interfaces  Ia and   Ib  which are represented= as stub networks owing to their definition on a point-to-point link betwee= n RT6 and RT10


On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem <acee@lindem.com> wrote:
Preet - Can you denote which boxes you changed and why? In its current stat= e, this errata should be summarily rejected.
Thanks,
Acee
On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3644 >
> --------------------------------------
> Type: Technical
> Reported by: Preet D'Souza <preet.desouza17@gmail.com>
>
> Section: 2.1.2
>
> Original Text
> -------------
>                     =                   **FROM**
>
>                 |RT|RT|RT|RT|R= T|RT|RT|RT|RT|RT|RT|RT|
>                 |1 |2 |3 |4 |5= |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
>              ----- ----------------= -----------------------------
>              RT1|  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |  |  |  |
>              RT2|  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |  |  |  |
>              RT3|  |  | &= nbsp;|  |  |6 |  |  |  |  |  |  |0 = |  |  |  |
>              RT4|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  |0 = |  |  |  |
>              RT5|  |  | &= nbsp;|8 |  |6 |6 |  |  |  |  |  |  | &nb= sp;|  |  |
>              RT6|  |  |8 = |  |7 |  |  |  |  |5 |  |  |  | &nb= sp;|  |  |
>              RT7|  |  | &= nbsp;|  |6 |  |  |  |  |  |  |  | &= nbsp;|0 |  |  |
>          *   RT8|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|0 |  |  |
>          *   RT9|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |0 |
>          T  RT10|  |  |  = |  |  |7 |  |  |  |  |  |  |  = |0 |0 |  |
>          O  RT11|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |0 |0 |
>          *  RT12|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |0 |
>          *    N1|3 |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N2|  |3 |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N3|1 |1 |1 |1 |  = ;|  |  |  |  |  |  |  |  |  | =  |  |
>               N4|  |  |2 = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N6|  |  | &= nbsp;|  |  |  |1 |1 |  |1 |  |  |  | &nb= sp;|  |  |
>               N7|  |  | &= nbsp;|  |  |  |  |4 |  |  |  |  | &= nbsp;|  |  |  |
>               N8|  |  | &= nbsp;|  |  |  |  |  |  |3 |2 |  |  = |  |  |  |
>               N9|  |  | &= nbsp;|  |  |  |  |  |1 |  |1 |1 |  | &nb= sp;|  |  |
>              N10|  |  | &= nbsp;|  |  |  |  |  |  |  |  |2 | &= nbsp;|  |  |  |
>              N11|  |  | &= nbsp;|  |  |  |  |  |3 |  |  |  | &= nbsp;|  |  |  |
>              N12|  |  | &= nbsp;|  |8 |  |2 |  |  |  |  |  |  = |  |  |  |
>              N13|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>              N14|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>              N15|  |  | &= nbsp;|  |  |  |9 |  |  |  |  |  | &= nbsp;|  |  |  |
>               H1|  |  | &= nbsp;|  |  |  |  |  |  |  |  |10| &= nbsp;|  |  |  |
>
>
> Corrected Text
> --------------
>                     =                **FROM**
>
>                 |RT|RT|RT|RT|R= T|RT|RT|RT|RT|RT|RT|RT|
>                 |1 |2 |3 |4 |5= |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
>              ----- ----------------= -----------------------------
>              RT1|  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |  |  |  |
>              RT2|  |  | &= nbsp;|  |  |  |  |  |  |  |  | &nbs= p;|0 |  |  |  |
>              RT3|  |  | &= nbsp;|  |  |6 |  |  |  |  |  |  |0 = |  |  |  |
>              RT4|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  |0 = |  |  |  |
>              RT5|  |  | &= nbsp;|8 |  |6 |6 |  |  |  |  |  |  | &nb= sp;|  |  |
>              RT6|  |  |8 = |  |7 |  |  |  |  |5 |  |  |  | &nb= sp;|  |  |
>              RT7|  |  | &= nbsp;|  |6 |  |  |  |  |  |  |  | &= nbsp;|0 |  |  |
>          *   RT8|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|0 |  |  |
>          *   RT9|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |0 |
>          T  RT10|  |  |  = |  |  |7 |  |  |  |  |  |  |  = |0 |0 |  |
>          O  RT11|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |0 |0 |
>          *  RT12|  |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |0 |
>          *    N1|3 |  |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N2|  |3 |  = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N3|1 |1 |1 |1 |  = ;|  |  |  |  |  |  |  |  |  | =  |  |
>               N4|  |  |2 = |  |  |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>               N6|  |  | &= nbsp;|  |  |  |1 |1 |  |1 |  |  |  | &nb= sp;|  |  |
>               N7|  |  | &= nbsp;|  |  |  |  |4 |  |  |  |  | &= nbsp;|  |  |  |
>               N8|  |  | &= nbsp;|  |  |  |  |  |  |3 |2 |  |  = |  |  |  |
>               N9|  |  | &= nbsp;|  |  |  |  |  |1 |  |1 |1 |  | &nb= sp;|  |  |
>              N10|  |  | &= nbsp;|  |  |  |  |  |  |  |  |2 | &= nbsp;|  |  |  |
>              N11|  |  | &= nbsp;|  |  |  |  |  |3 |  |  |  | &= nbsp;|  |  |  |
>              N12|  |  | &= nbsp;|  |8 |  |2 |  |  |  |  |  |  = |  |  |  |
>              N13|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>              N14|  |  | &= nbsp;|  |8 |  |  |  |  |  |  |  | &= nbsp;|  |  |  |
>              N15|  |  | &= nbsp;|  |  |  |9 |  |  |  |  |  | &= nbsp;|  |  |  |
>               H1|  |  | &= nbsp;|  |  |  |  |  |  |  |  |10| &= nbsp;|  |  |  |
>               Ia|  |  | &= nbsp;|  |  |  |  |  |  |5 |  |  | &= nbsp;|  |  |  |
>               Ib|  |  | &= nbsp;|  |  |7 |  |  |  |  |  |  | &= nbsp;|  |  |  |
>
> Notes
> -----
> section 2.1.2
>
> Page 20, Figure 2 : A sample Autonomous System.
>
> The interfaces   Ia  and Ib  have not been added to the= directed graph.
> By definition of point-to-point links under OSPF, for serial interface= s defined by IP addresses,
> router RT6 should advertise a stub network to Ib whereas router RT6 sh= ould advertise a stub network to Ia .
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title               : OSPF Version = 2
> Publication Date    : April 1998
> Author(s)           : J. Moy
> Category            : INTERNET STANDARD<= br> > Source              : Open Shortest= Path First IGP
> Area                : Routing<= br> > Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf





--_000_94A203EA12AECE4BA92D42DBFFE0AE4715F7DFeusaamb101ericsso_-- From preet.desouza17@gmail.com Fri Jun 7 22:32:06 2013 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 28AF421F8895 for ; Fri, 7 Jun 2013 22:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, NO_RELAYS=-0.001] 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 ChRyFfEOZrem for ; Fri, 7 Jun 2013 22:32:04 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 79ECF21F881F for ; Fri, 7 Jun 2013 22:32:04 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so1613616qcq.5 for ; Fri, 07 Jun 2013 22:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=183of4deCX1Jf+iiSKc9HkrTerbisu7QM+LE153TaBg=; b=Zzg4CZ2ABIwsXXcEavjlhcHENXXpAQGhgWpg3mpjo1YOCGRwL66ieNbh4cD6vHyXqJ s1w09MzJ7xpQihoTli2cqQfRD+4lQ3QObLtR4Gdph60k6N8pqNX68fKVvoK/7EWVHp1g dXVMeoSrAXRw0ON/qDLxaSUYaohwnfZRuCUsKrm1hn8N1zu4Z5hJ7KbQynAi9zFa+LnZ wftg2B2Waay52y8n1GAz3DiAEaJh8deNmNnl1ilXxhbGCMD/uamOoYXixqmRujkDpu3e oNJb5mhnPIDgTKtC83XFYbFt8JoXTtW2HpD/qmktYVyC7xXMfIhlCjCLuJej7RNhHOjU xQyQ== MIME-Version: 1.0 X-Received: by 10.229.4.205 with SMTP id 13mr608618qcs.149.1370669523891; Fri, 07 Jun 2013 22:32:03 -0700 (PDT) Received: by 10.224.74.2 with HTTP; Fri, 7 Jun 2013 22:32:03 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4715F7DF@eusaamb101.ericsson.se> References: <20130607194649.DFE7B62114@rfc-editor.org> <94A203EA12AECE4BA92D42DBFFE0AE4715F7DF@eusaamb101.ericsson.se> Date: Sat, 8 Jun 2013 11:02:03 +0530 Message-ID: From: Preet DSouza To: Acee Lindem Content-Type: multipart/alternative; boundary=000e0ce0743c13802504de9dde61 Cc: "" , RFC Errata System , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3644) 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: Sat, 08 Jun 2013 05:32:06 -0000 --000e0ce0743c13802504de9dde61 Content-Type: text/plain; charset=ISO-8859-1 Hello Acee, I disagree. To support my claim, I would like to draw your attention to Figure 1a. "Network Map Components". Kindly refer to the first pair of figures located at the top depicting the network map on the left and the directed graph on the right for physical point-to-point networks. You will clearly notice the presence of an edge from each router to the opposite router's interface in the directed graph. [ RT1 to Ib and RT2 to Ia] The explanation provided for point-to-point networks on Page [14] explains this. It reads, The top of Figure 1a shows two routers connected by a point-to- point link. In the resulting link-state database graph, the two router vertices are directly connected by a pair of edges, one in each direction. Interfaces to point-to-point networks need not be assigned IP addresses. *When interface addresses are assigned, they are modelled as stub links, with each router advertising a stub connection to the other router's interface address.* Optionally, an IP subnet can be assigned to the point- to-point network. In this case, both routers advertise a stub link to the IP subnet, instead of advertising each others' IP interface addresses. Thanks On Sat, Jun 8, 2013 at 9:15 AM, Acee Lindem wrote: > Hi Preet, > Figure 3 contains "The resulting directed graph". Since Ia and Ib are > simply the endpoints of a point-to-point network, they do not represent > vertexes in the directed graph and need not be included in figure 3. A > point-to-point link is imply an edge in the graph. My recommendation is > that your errata be rejected. > Thanks, > Acee > > On Jun 7, 2013, at 4:35 PM, Preet DSouza wrote: > > Kindly note that I've made a minor mistake in the RFC errata notes. > > It says, > > Notes: > > section 2.1.2 > > Page 20, Figure 2 : A sample Autonomous System. > > The interfaces Ia and Ib have not been added to the directed graph. > By definition of point-to-point links under OSPF, for serial interfaces > defined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router RT6 should > advertise a stub network to Ia . > > > It should say, > > Notes: > > section 2.1.2 > > Page 20, Figure 2 : A sample Autonomous System. > > The interfaces Ia and Ib have not been added to the directed graph. > By definition of point-to-point links under OSPF, for serial interfaces > defined by IP addresses, > router RT6 should advertise a stub network to Ib whereas router *RT10*should advertise a stub network to Ia . > > > > On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza wrote: > >> The corrected text should be as under. >> The additions are noted in bold. >> >> **FROM** >> >> |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >> |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >> ----- --------------------------------------------- >> RT1| | | | | | | | | | | | |0 | | | | >> RT2| | | | | | | | | | | | |0 | | | | >> RT3| | | | | |6 | | | | | | |0 | | | | >> RT4| | | | |8 | | | | | | | |0 | | | | >> RT5| | | |8 | |6 |6 | | | | | | | | | | >> RT6| | |8 | |7 | | | | |5 | | | | | | | >> RT7| | | | |6 | | | | | | | | |0 | | | >> * RT8| | | | | | | | | | | | | |0 | | | >> * RT9| | | | | | | | | | | | | | | |0 | >> T RT10| | | | | |7 | | | | | | | |0 |0 | | >> O RT11| | | | | | | | | | | | | | |0 |0 | >> * RT12| | | | | | | | | | | | | | | |0 | >> * N1|3 | | | | | | | | | | | | | | | | >> N2| |3 | | | | | | | | | | | | | | | >> N3|1 |1 |1 |1 | | | | | | | | | | | | | >> N4| | |2 | | | | | | | | | | | | | | >> N6| | | | | | |1 |1 | |1 | | | | | | | >> N7| | | | | | | |4 | | | | | | | | | >> N8| | | | | | | | | |3 |2 | | | | | | >> N9| | | | | | | | |1 | |1 |1 | | | | | >> N10| | | | | | | | | | | |2 | | | | | >> N11| | | | | | | | |3 | | | | | | | | >> N12| | | | |8 | |2 | | | | | | | | | | >> N13| | | | |8 | | | | | | | | | | | | >> N14| | | | |8 | | | | | | | | | | | | >> N15| | | | | | |9 | | | | | | | | | | >> H1| | | | | | | | | | | |10| | | | | >> *Ia| | | | | | | | | |5 | | | | | | |** >> Ib| | | | | |7 | | | | | | | | | | |* >> >> >> On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza wrote: >> >>> Hello Acee, >>> >>> I made two additions. >>> The last two rows in the **To** column have been added. >>> They are interfaces Ia and Ib which are represented as stub networks >>> owing to their definition on a point-to-point link between RT6 and RT10 >>> >>> >>> On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem wrote: >>> >>>> Preet - Can you denote which boxes you changed and why? In its current >>>> state, this errata should be summarily rejected. >>>> Thanks, >>>> Acee >>>> On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote: >>>> >>>> > The following errata report has been submitted for RFC2328, >>>> > "OSPF Version 2". >>>> > >>>> > -------------------------------------- >>>> > You may review the report below and at: >>>> > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3644 >>>> > >>>> > -------------------------------------- >>>> > Type: Technical >>>> > Reported by: Preet D'Souza >>>> > >>>> > Section: 2.1.2 >>>> > >>>> > Original Text >>>> > ------------- >>>> > **FROM** >>>> > >>>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>>> > ----- --------------------------------------------- >>>> > RT1| | | | | | | | | | | | |0 | | | | >>>> > RT2| | | | | | | | | | | | |0 | | | | >>>> > RT3| | | | | |6 | | | | | | |0 | | | | >>>> > RT4| | | | |8 | | | | | | | |0 | | | | >>>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>>> > RT7| | | | |6 | | | | | | | | |0 | | | >>>> > * RT8| | | | | | | | | | | | | |0 | | | >>>> > * RT9| | | | | | | | | | | | | | | |0 | >>>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>>> > * RT12| | | | | | | | | | | | | | | |0 | >>>> > * N1|3 | | | | | | | | | | | | | | | | >>>> > N2| |3 | | | | | | | | | | | | | | | >>>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>>> > N4| | |2 | | | | | | | | | | | | | | >>>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>>> > N7| | | | | | | |4 | | | | | | | | | >>>> > N8| | | | | | | | | |3 |2 | | | | | | >>>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>>> > N10| | | | | | | | | | | |2 | | | | | >>>> > N11| | | | | | | | |3 | | | | | | | | >>>> > N12| | | | |8 | |2 | | | | | | | | | | >>>> > N13| | | | |8 | | | | | | | | | | | | >>>> > N14| | | | |8 | | | | | | | | | | | | >>>> > N15| | | | | | |9 | | | | | | | | | | >>>> > H1| | | | | | | | | | | |10| | | | | >>>> > >>>> > >>>> > Corrected Text >>>> > -------------- >>>> > **FROM** >>>> > >>>> > |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| >>>> > |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| >>>> > ----- --------------------------------------------- >>>> > RT1| | | | | | | | | | | | |0 | | | | >>>> > RT2| | | | | | | | | | | | |0 | | | | >>>> > RT3| | | | | |6 | | | | | | |0 | | | | >>>> > RT4| | | | |8 | | | | | | | |0 | | | | >>>> > RT5| | | |8 | |6 |6 | | | | | | | | | | >>>> > RT6| | |8 | |7 | | | | |5 | | | | | | | >>>> > RT7| | | | |6 | | | | | | | | |0 | | | >>>> > * RT8| | | | | | | | | | | | | |0 | | | >>>> > * RT9| | | | | | | | | | | | | | | |0 | >>>> > T RT10| | | | | |7 | | | | | | | |0 |0 | | >>>> > O RT11| | | | | | | | | | | | | | |0 |0 | >>>> > * RT12| | | | | | | | | | | | | | | |0 | >>>> > * N1|3 | | | | | | | | | | | | | | | | >>>> > N2| |3 | | | | | | | | | | | | | | | >>>> > N3|1 |1 |1 |1 | | | | | | | | | | | | | >>>> > N4| | |2 | | | | | | | | | | | | | | >>>> > N6| | | | | | |1 |1 | |1 | | | | | | | >>>> > N7| | | | | | | |4 | | | | | | | | | >>>> > N8| | | | | | | | | |3 |2 | | | | | | >>>> > N9| | | | | | | | |1 | |1 |1 | | | | | >>>> > N10| | | | | | | | | | | |2 | | | | | >>>> > N11| | | | | | | | |3 | | | | | | | | >>>> > N12| | | | |8 | |2 | | | | | | | | | | >>>> > N13| | | | |8 | | | | | | | | | | | | >>>> > N14| | | | |8 | | | | | | | | | | | | >>>> > N15| | | | | | |9 | | | | | | | | | | >>>> > H1| | | | | | | | | | | |10| | | | | >>>> > Ia| | | | | | | | | |5 | | | | | | | >>>> > Ib| | | | | |7 | | | | | | | | | | | >>>> > >>>> > Notes >>>> > ----- >>>> > section 2.1.2 >>>> > >>>> > Page 20, Figure 2 : A sample Autonomous System. >>>> > >>>> > The interfaces Ia and Ib have not been added to the directed >>>> graph. >>>> > By definition of point-to-point links under OSPF, for serial >>>> interfaces defined by IP addresses, >>>> > router RT6 should advertise a stub network to Ib whereas router RT6 >>>> should advertise a stub network to Ia . >>>> > >>>> > Instructions: >>>> > ------------- >>>> > This errata is currently posted as "Reported". If necessary, please >>>> > use "Reply All" to discuss whether it should be verified or >>>> > rejected. When a decision is reached, the verifying party (IESG) >>>> > can log in to change the status and edit the report, if necessary. >>>> > >>>> > -------------------------------------- >>>> > RFC2328 (no draft string recorded) >>>> > -------------------------------------- >>>> > Title : OSPF Version 2 >>>> > Publication Date : April 1998 >>>> > Author(s) : J. Moy >>>> > Category : INTERNET STANDARD >>>> > Source : Open Shortest Path First IGP >>>> > Area : Routing >>>> > Stream : IETF >>>> > Verifying Party : IESG >>>> > _______________________________________________ >>>> > OSPF mailing list >>>> > OSPF@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> >>> >> > > --000e0ce0743c13802504de9dde61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Acee,

I disagree.=A0
<= div style>To support my claim, I would like to draw your attention to Figur= e 1a. "Network Map Components". Kindly refer to the first pair of= figures located at the top depicting the
network map on the left and the directed graph on the right for = physical point-to-point networks.

You = will clearly notice the presence of an edge from each router to the opposit= e router's interface in the directed graph. [ RT1 to =A0Ib =A0 =A0 and = =A0 =A0 RT2 =A0 to =A0Ia]

The explanation provided for point-to-point= networks on Page [14] explains this. It reads,

<= div style>
        The top of Figure 1a shows two routers connected by a point-to-
        point link. In the resulting link-state database graph, the two
        router vertices are directly connected by a pair of edges, one
        in each direction. Interfaces to point-to-point networks need
        not be assigned IP addresses.  When interface addresses are
        assigned, they are modelled as stub links, with each router
        advertising a stub connection to the other router's interface
        address. Optionally, an IP subnet can be assigned to the point-
        to-point network. In this case, both routers advertise a stub
        link to the IP subnet, instead of advertising each others' IP
        interface addresses.

Thanks

On Sa= t, Jun 8, 2013 at 9:15 AM, Acee Lindem <acee.lindem@ericsson.com> wrote:
Hi Preet,
Figure 3 contains "The resulting directed graph". Since Ia a= nd Ib are simply the endpoints of a point-to-point network, they do not rep= resent vertexes in the directed graph and need not be included in figure 3.= A point-to-point link is imply an edge in the graph. My recommendation is that your errata be rejected.=A0
Thanks,
Acee

On Jun 7, 2013, at 4:35 PM, Preet DSouza wrote:

Kindly note that I've made a minor mistake in the RFC = errata notes.

It says,

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces def= ined by IP addresses,
router RT6 should advertise a stub network to Ib whereas router RT6 should = advertise a stub network to Ia .


It should say,

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the direct= ed graph.
By definition of point-to-point links under OSPF, for seri= al interfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whereas r= outer RT10 should advertise a stu= b network to Ia .




On Sat, Jun 8, 2013 at 1:59 AM, Preet DSouza <preet.de= souza17@gmail.com> wrote:
=A0 =A0 The corrected text should be as under.=A0
=A0 =A0 Th= e additions are noted in bold.=A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0**FROM**

=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 ----- ---------------------------------------------
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0|= 0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= 0 | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| =A0|5 | =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|0 | =A0| =A0|
=A0 =A0 =A0 =A0= =A0 * =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0|0 | =A0| =A0|
=A0 =A0 =A0 =A0= =A0 * =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0|0 |
=A0 =A0 =A0 =A0= =A0 T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0|0 |0 | =A0|
=A0 =A0 =A0 =A0= =A0 O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0|0 |0 |
=A0 =A0 =A0 =A0= =A0 * =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0|0 |
=A0 =A0 =A0 =A0= =A0 * =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | =A0|1 | =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 |2 | =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1 | =A0|1 |1 | = =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|2 |= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|3 | =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| =A0| =A0| =A0| =A0|= =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|1= 0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|5 | =A0= | =A0| =A0| =A0| =A0| =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0|


On Sat, Jun 8, 2013 at 1:44 AM, Preet DSouza <preet.de= souza17@gmail.com> wrote:
Hello Acee,

I made two additions.=A0
The last two rows in the **To** column have been added.
They are interfaces =A0Ia and =A0 Ib =A0which are represented as stub = networks owing to their definition on a point-to-point link between RT6 and= RT10


On Sat, Jun 8, 2013 at 1:29 AM, Acee Lindem <acee@lindem.com> wrote:
Preet - Can you denote which boxes you changed and why? In its current stat= e, this errata should be summarily rejected.
Thanks,
Acee
On Jun 7, 2013, at 3:46 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3644 >
> --------------------------------------
> Type: Technical
> Reported by: Preet D'Souza <preet.desouza17@gmail.com>
>
> Section: 2.1.2
>
> Original Text
> -------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 **FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
>
>
> Corrected Text
> --------------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0**FROM**
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N= 3|N6|N8|N9|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0----- -------------------------------------= --------
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT2| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT3| =A0| =A0| =A0| =A0| =A0|6 | =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT4| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0|0 | =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT5| =A0| =A0| =A0|8 | =A0|6 |6 | =A0| =A0|= =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT6| =A0| =A0|8 | =A0|7 | =A0| =A0| =A0| = =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0RT7| =A0| =A0| =A0| =A0|6 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 | =A0| =A0|
> =A0 =A0 =A0 =A0 =A0* =A0 RT9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0T =A0RT10| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0|0 |0 | =A0|
> =A0 =A0 =A0 =A0 =A0O =A0RT11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0|0 |0 |
> =A0 =A0 =A0 =A0 =A0* =A0RT12| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|0 |
> =A0 =A0 =A0 =A0 =A0* =A0 =A0N1|3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N2| =A0|3 | =A0| =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N3|1 |1 |1 |1 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N4| =A0| =A0|2 | =A0| =A0| =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N6| =A0| =A0| =A0| =A0| =A0| =A0|1 |1 | = =A0|1 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N7| =A0| =A0| =A0| =A0| =A0| =A0| =A0|4 | = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N8| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|3 |2 | =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 N9| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |1 | =A0|1 |1 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N10| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|2 | =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N11| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= |3 | =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N12| =A0| =A0| =A0| =A0|8 | =A0|2 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N13| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N14| =A0| =A0| =A0| =A0|8 | =A0| =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0N15| =A0| =A0| =A0| =A0| =A0| =A0|9 | =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 H1| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0| =A0| =A0|10| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ia| =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0= | =A0|5 | =A0| =A0| =A0| =A0| =A0| =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ib| =A0| =A0| =A0| =A0| =A0|7 | =A0| =A0| = =A0| =A0| =A0| =A0| =A0| =A0| =A0| =A0|
>
> Notes
> -----
> section 2.1.2
>
> Page 20, Figure 2 : A sample Autonomous System.
>
> The interfaces =A0 Ia =A0and Ib =A0have not been added to the directed= graph.
> By definition of point-to-point links under OSPF, for serial interface= s defined by IP addresses,
> router RT6 should advertise a stub network to Ib whereas router RT6 sh= ould advertise a stub network to Ia .
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : OSPF Version 2
> Publication Date =A0 =A0: April 1998
> Author(s) =A0 =A0 =A0 =A0 =A0 : J. Moy
> Category =A0 =A0 =A0 =A0 =A0 =A0: INTERNET STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Open Shortest Path First IGP
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf






--000e0ce0743c13802504de9dde61-- From prvs=4871105c1b=acee.lindem@ericsson.com Sat Jun 8 04:47:13 2013 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 1D53021F880F for ; Sat, 8 Jun 2013 04:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 U6W1vLRmECnd for ; Sat, 8 Jun 2013 04:47:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9D21F8763 for ; Sat, 8 Jun 2013 04:47:07 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-1c-51b319ba700d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 75.14.05617.AB913B15; Sat, 8 Jun 2013 13:47:07 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sat, 8 Jun 2013 07:47:06 -0400 From: Acee Lindem To: Alan Davey Thread-Topic: [OSPF] draft-acee-ospfv3-lsa-extend-00 Thread-Index: Ac5dKNOXxrjjra7QRqKAriZTB+i9+QHNpf+A Date: Sat, 8 Jun 2013 11:47:05 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715FBE3@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4715FBE3eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonSne35OZAgwnTmSyeTJvFZrHt5x82 i5Z799gdmD2WLPnJ5HH05lxmjy+XP7MFMEdx2yQllpQFZ6bn6dslcGdsm32PvaDHteLKk9fM DYz7bboYOTkkBEwk5vyfwgRhi0lcuLeeDcQWEjjKKHFyl2AXIxeQvYxRYt6ir4wgCTYBHYnn j/4xg9giAloSO6Z/ZgMpYhZoYZT4d+8yC0hCWMBY4v6DNWwQRSYS7xofskPYRkDbVoMNYhFQ keh8+pcVxOYV8JZYOXMWUC8H0DY/iQsfHEDCnAL+EpvePAMrYQQ67vupNWCHMguIS9x6Mh/q aAGJJXvOM0PYohIvH/9jhbCVJb7PecQCUZ8v0Tx7PtQqQYmTM5+wTGAUnYVk1CwkZbOQlEHE DSTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLXHzwxR2ZDULGDlWMXKUFqeW5aYbGW5iBMbgMQk2 xx2MCz5ZHmKU5mBREufV4V0cKCSQnliSmp2aWpBaFF9UmpNafIiRiYMTRHBJNTBuMFu4OHBy yos10TafLz+xF5OfZX2ZKXhGQ8VWo1Wcm5qfXi55kb28zqaebf7Pmbf2bj/wt0xaIPtBcvuU nPRDx6tCnr9MtLpiyNhrejz61ew1h/68DF9zzM2+zcVZPZJp46nqAL9JT9oWzt7mIL76uvK+ ffNsxGd5bnhRa3/kys5jYVutlkqsUmIpzkg01GIuKk4EAFWSdfiUAgAA Cc: "ospf@ietf.org" , "draft-acee-ospfv3-lsa-extend@tools.ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 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: Sat, 08 Jun 2013 11:47:13 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4715FBE3eusaamb101ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alan, On May 30, 2013, at 7:28 AM, Alan Davey wrote: Folks I have read draft-acee-ospfv3-lsa-extend-00 and found it interesting. It i= s clearly non-back-compatible with existing implementations of OSPFv3, but = there is not much in the draft about the requirements. Could the authors p= lease give some more details on what is driving the need for the LSA extens= ions? We can add references to the draft that are dependent on this extension. http://www.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-routing-02.txt http://www.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-02.txt There are other applications as well. For example, the previous draft suppo= rting IPv4 and IPv6 in a single address family and multiple topologies in a= single instance. As an aside, the draft does not appear on the WG=92s Documents page on the = IETF site. Is this because the draft should have =93ospf=94 in its title, = that is, =93draft-acee-ospf-ospfv3-lsa-extend=94? This is because it not a WG document yet. Thanks, Acee Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_94A203EA12AECE4BA92D42DBFFE0AE4715FBE3eusaamb101ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Alan,

On May 30, 2013, at 7:28 AM, Alan Davey wrote:

Folks
 
I have read draft-acee-ospfv3-lsa-extend-00 and found it interesting. = It is clearly non-back-compatible with existing implementations of OSPFv3,= but there is not much in the draft about the requirements.  Could the= authors please give some more details on what is driving the need for the LSA extensions?

We can add references to the draft that are dependent on this extensio= n. 


There are other applications as well. For example, the previous draft = supporting IPv4 and IPv6 in a single address family and multiple topologies= in a single instance.  


 
As an aside, the draft does not appear on the WG=92s Documents page on the = IETF site.  Is this because the draft should have =93ospf=94 in its ti= tle, that is, =93draft-acee-ospf-ospfv3-lsa-extend=94?

This is because it not a WG document yet. 

Thanks,
Acee


 
Regards
Alan Davey
 
Networ= k Technologies
Metaswitch Networks<= /span>
&nbs= p;
 
 
 
 

--_000_94A203EA12AECE4BA92D42DBFFE0AE4715FBE3eusaamb101ericsso_-- From chenxibj@cn.ibm.com Sun Jun 9 13:12:34 2013 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 2973021F85EB for ; Sun, 9 Jun 2013 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 RIwuSQqGoCHA for ; Sun, 9 Jun 2013 13:12:27 -0700 (PDT) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id DFECD21F85C3 for ; Sun, 9 Jun 2013 13:12:26 -0700 (PDT) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Jun 2013 06:02:41 +1000 Received: from d23dlp03.au.ibm.com (202.81.31.214) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 10 Jun 2013 06:02:40 +1000 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 983BF3578045 for ; Mon, 10 Jun 2013 06:11:49 +1000 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r59JvHhv524628 for ; Mon, 10 Jun 2013 05:57:19 +1000 Received: from d23av05.au.ibm.com (loopback [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r59KBlsu015477 for ; Mon, 10 Jun 2013 06:11:48 +1000 Received: from d23ml021.cn.ibm.com (d23ml021.cn.ibm.com [9.119.32.97]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r59KBlCm015469 for ; Mon, 10 Jun 2013 06:11:47 +1000 Auto-Submitted: auto-generated From: Xi R Chen To: ospf@ietf.org Message-ID: Date: Mon, 10 Jun 2013 04:09:52 +0800 X-MIMETrack: Serialize by Router on d23ml021/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 06/10/2013 04:09:54 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF116DFFD42CE8f9e8a93df938690918cC7BBF116DFFD42CE" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13060920-5490-0000-0000-0000039DCA1B Subject: [OSPF] AUTO: Xi R Chen is out of the office (returning 06/17/2013) 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: Sun, 09 Jun 2013 20:12:34 -0000 --0__=C7BBF116DFFD42CE8f9e8a93df938690918cC7BBF116DFFD42CE Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 06/17/2013. Note: This is an automated response to your message "OSPF Digest, Vol = 88, Issue 9" sent on 06/08/2013 11:45:47. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF116DFFD42CE8f9e8a93df938690918cC7BBF116DFFD42CE Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 06= /17/2013.




Note: Thi= s is an automated response to your message  "OSPF Digest, Vol 88, Issue 9" sent = on 06/08/2013 11:45:47.

This is t= he only notification you will receive while this person is away.= = --0__=C7BBF116DFFD42CE8f9e8a93df938690918cC7BBF116DFFD42CE-- From prvs=887411684e=acee.lindem@ericsson.com Tue Jun 11 04:35:32 2013 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 6553421F93B9 for ; Tue, 11 Jun 2013 04:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 c0OmW-rEUOEZ for ; Tue, 11 Jun 2013 04:35:27 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DC3A721F8EB3 for ; Tue, 11 Jun 2013 04:35:26 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-de-51b70b7e5b0d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BC.BD.05617.E7B07B15; Tue, 11 Jun 2013 13:35:26 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 07:35:25 -0400 From: Acee Lindem To: Michael Barnes , "ospf@ietf.org" Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGg== Date: Tue, 11 Jun 2013 11:35:23 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> In-Reply-To: <51B0ED10.1090007@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B6DEB3424C59446A9E2D019CC7EB64E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPiG4d9/ZAgxvzJCwWr3vFYtFy7x67 A5PHlN8bWT2WLPnJFMAUxW2TlFhSFpyZnqdvl8CdcXHRL6aC1/IV6y6+YGpgbJbsYuTkkBAw kdh5rpcVwhaTuHBvPVsXIxeHkMBRRonp7x8wQzjLGSWeH17HCFLFJqAj8fzRP2YQW0TAQ2Lf +RVgtrBAiMS5lpNANRxA8VCJM5tqIUw9idsXw0EqWARUJVoPTgHbxSvgLfH86luwTk4BTYnZ h3eDTWcEuuH7qTVMIDazgLjErSfzmSBuE5BYsuc8M4QtKvHy8T+wOaJA49uOnWGHiCtLLHmy nwWiV0diwe5PbBC2tcTaq88YIWxtiWULXzND3CAocXLmE5YJjGKzkKybhaR9FpL2WUjaZyFp X8DIuoqRo7Q4tSw33chwEyMweo5JsDnuYFzwyfIQozQHi5I4rw7v4kAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnCCCS6qBUX3r1KS/e6b4LAuIPr9X527GogbFG/PUN7ebv1z73KbM2049Yu7f wM3q1T/Dvy3xqTJZJv/Mp+KETVfP68TN7lyPDklFtsjY5esteSR06DTbxQtF5lavhCpy1Gv7 Hq2YM9ulRcriaqRX5FMhO0OxfQt7WtkPJfO5ZS6xXbun8N/BrWvvaor6K7EUZyQaajEXFScC AGAh8nZxAgAA Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Tue, 11 Jun 2013 11:35:32 -0000 Thank Michael - Does anyone else support this work? I think it will help ensure compatibility between implementations. I would have expected at least those who submitted the corrected errata to support the draft. Thanks, Acee On 6/6/13 1:12 PM, "Michael Barnes" wrote: >I agree these are good changes. Acee, please move forward with this draft. > >Thanks, >Michael > >On 05/09/2013 11:03 AM, Acee Lindem wrote: >> There have been a couple errata filed on RFC 6505 (authors copied). As >>a service to the >> OSPF community and in an effort to ensure interoperable OSPFv3 >>authentication >> trailer implementations, I have produced a BIS draft. The changes are >>listed in >> section 1.2: >> >> 1.2. Summary of Changes from RFC 6506 >> >> This document includes the following changes from RFC 6506 >>[RFC6506]: >> >> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >> (LLS) block checksum calculation is omitted when an OSPFv3 >> authentication is used. The LLS block is included in the >> authentication digest calculation and computation of a checksum >> is unneccessary. Clarification of this issue was raised in an >> errata. >> >> 2. Section 4.5 includes a correction to the key preparation to use >> the protocol specific key (Ks) rather than the key (K) as the >> initial key (Ko). This problem was also raised in an errata. >> >> 3. Section 4.5 also includes a discussion of the choice of key >> length to be the hash length (L) rather than the block size (B). >> The discussion of this choice was included to clarify an issue >> raised in a rejected errata. >> >> 4. Section 4.1 indicates that sequence number checking is dependent >> on OSPFv3 packet type in order to account for packet >> prioritization as specified in [RFC4222]. This was an omission >> from RFC 6506. >> >> >> I would like to quickly move this to an OSPF WG document and begin the >>review process. I'm now soliciting feedback on OSPF WG adoption. >> >> Thanks, >> Acee >> >> >> On May 9, 2013, at 1:43 PM, >> wrote: >> >>> >>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt >>> has been successfully submitted by Manav Bhatia and posted to the >>> IETF repository. >>> >>> Filename: draft-acee-ospf-rfc6506bis >>> Revision: 01 >>> Title: Supporting Authentication Trailer for OSPFv3 >>> Creation date: 2013-05-09 >>> Group: Individual Submission >>> Number of pages: 25 >>> URL: =20 >>>http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>> Status: =20 >>>http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>> Htmlized: =20 >>>http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>> Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>> >>> Abstract: >>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>> for authenticating protocol packets. This behavior is different >>>from >>> authentication mechanisms present in other routing protocols >>>(OSPFv2, >>> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >>> Information Protocol Next Generation (RIPng)). In some >>>environments, >>> it has been found that IPsec is difficult to configure and maintain >>> and thus cannot be used. This document defines an alternative >>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 >>>does >>> not only depend upon IPsec for authentication. This document >>> obsoletes RFC 6506. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> 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 mkarasek@cisco.com Tue Jun 11 06:26:19 2013 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 631D021F8EBE for ; Tue, 11 Jun 2013 06:26:19 -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 co0-ijnRXNzT for ; Tue, 11 Jun 2013 06:26:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8A21F8EEA for ; Tue, 11 Jun 2013 06:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5658; q=dns/txt; s=iport; t=1370957174; x=1372166774; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3wWkbjOgQt/RW9AvmA5rSi+C9G8L5OnYexI9N5HsUWk=; b=YcgKZ6ikEDja0tXcJIG7OASiZRMKj5MjRssAl2HIcr17dCGi2vLYjyjh DFZGqbnzBJai23oQDSpgrFgR4Nnzpe9cAU145um9txUocUjDCZJ4MR9BJ FJ3UmflOd+kKw2aS2TlqXuB2UWJ6VdycdCXmzPdhQVz6qYoJy7DR2eLoe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAolt1GtJXHA/2dsb2JhbABZgwkwQwa+S30WdIIjAQEBBAEBATc0CQ4EAgEIEQQBAQEKCwkJBycLFAkIAgQBEggBC4d5BwW6PI8BOAYEgnVhA5NuhHuQGYMPgic X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="221399844" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jun 2013 13:26:01 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5BDQ1Y4015552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 13:26:01 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.81]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 08:26:01 -0500 From: "Marek Karasek (mkarasek)" To: Acee Lindem , "Michael Barnes (mjbarnes)" , "ospf@ietf.org" Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfPs+Y9akuG1Uyjl0ojg1ZQuZkwfPcw Date: Tue, 11 Jun 2013 13:26:00 +0000 Message-ID: References: <51B0ED10.1090007@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.25.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Tue, 11 Jun 2013 13:26:19 -0000 Hi Acee, I support bis version as well. I have one more suggestion though for this paragraph: In support of uninterrupted deployment, an OSPFv3 router implementing this specification MAY implement a transition mode where it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets. This is provided as a transition aid for networks in the process of migrating to the authentication mechanism described in this specification. Can it be explicitly added how to work with checksums in the transition (or= deployment) mode? I suggest adding: - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3 heade= r checksum and LLS data block checksum is computed and written in the packe= ts. - For packets received in deployment mode which include an OSPFv3 Authentic= ation Trailer, OSPFv3 header checksum verification MUST be omitted. - For packets received in deployment mode which do not include an OSPFv3 Au= thentication Trailer, OSPFv3 header checksum and LLS data block checksum ar= e verified. =20 Thanks marek -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Tuesday, June 11, 2013 1:35 PM To: Michael Barnes (mjbarnes); ospf@ietf.org Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis= -01.txt Thank Michael - Does anyone else support this work? I think it will help en= sure compatibility between implementations. I would have expected at least = those who submitted the corrected errata to support the draft. Thanks, Acee On 6/6/13 1:12 PM, "Michael Barnes" wrote: >I agree these are good changes. Acee, please move forward with this draft. > >Thanks, >Michael > >On 05/09/2013 11:03 AM, Acee Lindem wrote: >> There have been a couple errata filed on RFC 6505 (authors copied).=20 >>As a service to the OSPF community and in an effort to ensure=20 >>interoperable OSPFv3 authentication trailer implementations, I have=20 >>produced a BIS draft. The changes are listed in section 1.2: >> >> 1.2. Summary of Changes from RFC 6506 >> >> This document includes the following changes from RFC 6506 >>[RFC6506]: >> >> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >> (LLS) block checksum calculation is omitted when an OSPFv3 >> authentication is used. The LLS block is included in the >> authentication digest calculation and computation of a checksum >> is unneccessary. Clarification of this issue was raised in an >> errata. >> >> 2. Section 4.5 includes a correction to the key preparation to use >> the protocol specific key (Ks) rather than the key (K) as the >> initial key (Ko). This problem was also raised in an errata. >> >> 3. Section 4.5 also includes a discussion of the choice of key >> length to be the hash length (L) rather than the block size (B). >> The discussion of this choice was included to clarify an issue >> raised in a rejected errata. >> >> 4. Section 4.1 indicates that sequence number checking is dependent >> on OSPFv3 packet type in order to account for packet >> prioritization as specified in [RFC4222]. This was an omission >> from RFC 6506. >> >> >> I would like to quickly move this to an OSPF WG document and begin=20 >>the review process. I'm now soliciting feedback on OSPF WG adoption. >> >> Thanks, >> Acee >> >> >> On May 9, 2013, at 1:43 PM, >> wrote: >> >>> >>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been=20 >>> successfully submitted by Manav Bhatia and posted to the IETF=20 >>> repository. >>> >>> Filename: draft-acee-ospf-rfc6506bis >>> Revision: 01 >>> Title: Supporting Authentication Trailer for OSPFv3 >>> Creation date: 2013-05-09 >>> Group: Individual Submission >>> Number of pages: 25 >>> URL: =20 >>>http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>> Status: =20 >>>http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>> Htmlized: =20 >>>http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>> Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>> >>> Abstract: >>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>> for authenticating protocol packets. This behavior is different=20 >>>from >>> authentication mechanisms present in other routing protocols=20 >>>(OSPFv2, >>> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >>> Information Protocol Next Generation (RIPng)). In some=20 >>>environments, >>> it has been found that IPsec is difficult to configure and maintain >>> and thus cannot be used. This document defines an alternative >>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3=20 >>>does >>> not only depend upon IPsec for authentication. This document >>> obsoletes RFC 6506. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From prvs=58741635f7=acee.lindem@ericsson.com Tue Jun 11 06:43:58 2013 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 5884521F99C1 for ; Tue, 11 Jun 2013 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 WAZUOxDnvOTy for ; Tue, 11 Jun 2013 06:43:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B88BD21F99BD for ; Tue, 11 Jun 2013 06:43:36 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-82-51b729887ad5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EB.C7.17537.88927B15; Tue, 11 Jun 2013 15:43:36 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 09:43:35 -0400 From: Acee Lindem To: "Marek Karasek (mkarasek)" Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGpkwxEsAgAAE6QA= Date: Tue, 11 Jun 2013 13:43:34 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47163A7A@eusaamb101.ericsson.se> References: <51B0ED10.1090007@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E19898B4DEB774CA077C0046ABB61AB@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPrG6H5vZAg6sTJC0Wr3vFYvHzSyer Rcu9e+wOzB5Tfm9k9Viy5CdTAFMUt01SYklZcGZ6nr5dAnfG2c03WQsuGVS0nF7K3sDYpN7F yMkhIWAi0X/9PxuELSZx4d56IJuLQ0jgKKPEhp+7WCCc5YwS3a17warYBHQknj/6x9zFyMEh ImAsMesOK0iYWSBc4urh/8wgtrBAiMS5lpOMECWhEmc21YKERQSsJI7OPcsCYrMIqEqc23iO CcTmFfCW2LJrITvEqrWMEns/PGcESXAK+EocnNIPNp8R6Ljvp9YwQewSl7j1ZD4TxNECEkv2 nGeGsEUlXj7+xwphK0ssebKfBaJeR2LB7k9sELa1xP5Na6Bu1pZYtvA1M8QRghInZz5hmcAo PgvJillI2mchaZ+FpH0WkvYFjKyrGDlKi1PLctONDDYxAiPsmASb7g7GPS8tDzFKc7AoifOq 8S4OFBJITyxJzU5NLUgtii8qzUktPsTIxMEJIrikGhhzD56SKZAo//bvpdjqw9qXT2RND3/g XqNw9/TSzByPU7OM9smmfDctTDINdthyRVz9nnulw6Je9tAKp2y9groTszZ82C82dU/Nvt0q t0NjPr05/GZ+RZHKqQV3o3neHUjJu2UX/+3avbwFz+cdmsXOHuttwiV1aY771zq9KKlrKRv1 Pt2anLlQiaU4I9FQi7moOBEA/KRgEoMCAAA= Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Tue, 11 Jun 2013 13:43:58 -0000 Hi Marek,=20 I've thought about it and this would be compatible with the rest of the dra= ft. It would be useful if incremental deployment is a concern. I have no ob= jection to adding this. Any other opinions?=20 Thanks, Acee On Jun 11, 2013, at 9:26 AM, Marek Karasek (mkarasek) wrote: > Hi Acee, >=20 > I support bis version as well. >=20 > I have one more suggestion though for this paragraph: >=20 > In support of uninterrupted deployment, an OSPFv3 router implementing > this specification MAY implement a transition mode where it includes > the Authentication Trailer in transmitted packets but does not verify > this information in received packets. This is provided as a > transition aid for networks in the process of migrating to the > authentication mechanism described in this specification. >=20 >=20 > Can it be explicitly added how to work with checksums in the transition (= or deployment) mode? I suggest adding: >=20 > - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3 hea= der checksum and LLS data block checksum is computed and written in the pac= kets. > - For packets received in deployment mode which include an OSPFv3 Authent= ication Trailer, OSPFv3 header checksum verification MUST be omitted. > - For packets received in deployment mode which do not include an OSPFv3 = Authentication Trailer, OSPFv3 header checksum and LLS data block checksum = are verified. >=20 >=20 > Thanks marek >=20 >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of A= cee Lindem > Sent: Tuesday, June 11, 2013 1:35 PM > To: Michael Barnes (mjbarnes); ospf@ietf.org > Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506b= is-01.txt >=20 > Thank Michael - Does anyone else support this work? I think it will help = ensure compatibility between implementations. I would have expected at leas= t those who submitted the corrected errata to support the draft. > Thanks, > Acee >=20 > On 6/6/13 1:12 PM, "Michael Barnes" wrote: >=20 >> I agree these are good changes. Acee, please move forward with this draf= t. >>=20 >> Thanks, >> Michael >>=20 >> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>> There have been a couple errata filed on RFC 6505 (authors copied).=20 >>> As a service to the OSPF community and in an effort to ensure=20 >>> interoperable OSPFv3 authentication trailer implementations, I have=20 >>> produced a BIS draft. The changes are listed in section 1.2: >>>=20 >>> 1.2. Summary of Changes from RFC 6506 >>>=20 >>> This document includes the following changes from RFC 6506 >>> [RFC6506]: >>>=20 >>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >>> (LLS) block checksum calculation is omitted when an OSPFv3 >>> authentication is used. The LLS block is included in the >>> authentication digest calculation and computation of a checksum >>> is unneccessary. Clarification of this issue was raised in an >>> errata. >>>=20 >>> 2. Section 4.5 includes a correction to the key preparation to use >>> the protocol specific key (Ks) rather than the key (K) as the >>> initial key (Ko). This problem was also raised in an errata. >>>=20 >>> 3. Section 4.5 also includes a discussion of the choice of key >>> length to be the hash length (L) rather than the block size (B). >>> The discussion of this choice was included to clarify an issue >>> raised in a rejected errata. >>>=20 >>> 4. Section 4.1 indicates that sequence number checking is dependent >>> on OSPFv3 packet type in order to account for packet >>> prioritization as specified in [RFC4222]. This was an omission >>> from RFC 6506. >>>=20 >>>=20 >>> I would like to quickly move this to an OSPF WG document and begin=20 >>> the review process. I'm now soliciting feedback on OSPF WG adoption. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>> On May 9, 2013, at 1:43 PM, >>> wrote: >>>=20 >>>>=20 >>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been=20 >>>> successfully submitted by Manav Bhatia and posted to the IETF=20 >>>> repository. >>>>=20 >>>> Filename: draft-acee-ospf-rfc6506bis >>>> Revision: 01 >>>> Title: Supporting Authentication Trailer for OSPFv3 >>>> Creation date: 2013-05-09 >>>> Group: Individual Submission >>>> Number of pages: 25 >>>> URL: =20 >>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>>> Status: =20 >>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>> Htmlized: =20 >>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>> Diff: =20 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>>>=20 >>>> Abstract: >>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>> for authenticating protocol packets. This behavior is different=20 >>>> from >>>> authentication mechanisms present in other routing protocols=20 >>>> (OSPFv2, >>>> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >>>> Information Protocol Next Generation (RIPng)). In some=20 >>>> environments, >>>> it has been found that IPsec is difficult to configure and maintain >>>> and thus cannot be used. This document defines an alternative >>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3=20 >>>> does >>>> not only depend upon IPsec for authentication. This document >>>> obsoletes RFC 6506. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=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 iesg-secretary@ietf.org Tue Jun 11 07:11:13 2013 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 0692821F9925; Tue, 11 Jun 2013 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_BACKHAIR_44=1, NO_RELAYS=-0.001, 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 NGq5MyWJkBHM; Tue, 11 Jun 2013 07:11:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6B721F9950; Tue, 11 Jun 2013 07:11:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p1 Message-ID: <20130611141112.4456.69359.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2013 07:11:12 -0700 Cc: ospf mailing list , ospf chair , RFC Editor Subject: [OSPF] Document Action: 'Routing for IPv4-embedded IPv6 Packets' to Informational RFC (draft-ietf-ospf-ipv4-embedded-ipv6-routing-14.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: Tue, 11 Jun 2013 14:11:13 -0000 The IESG has approved the following document: - 'Routing for IPv4-embedded IPv6 Packets' (draft-ietf-ospf-ipv4-embedded-ipv6-routing-14.txt) as Informational RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing/ Technical Summary This document describes routing packets destined to IPv4-embedded IPv6 addresses across an IPv6 core using OSPFv3 with a separate routing table. Working Group Summary Although presented at multiple IETFs, the draft did not generate a lot of comments. At one point, it included changes to the OSPFv3 protocol due to the suggestion that the IPv4 domains could be abstracted as OSPFv3 areas. This was discarded due to the complexity and the fact that it was above and beyond the RFC 5838 mechanisms. Document Quality The document has gone through several WG review cycles and revisions. Comments were received from some WG members as well as the chair of the BEHAVE WG. To the best of my knowledge, there are no implementations. We also WG last called the draft in the BEHAVE WG and received some comments from Brian Carpenter relative to positioning the draft with other IPv4<->IPv6 transition mechanisms. The latest version of the draft clarifies this. Personnel Acee Lindem is the document shepherd and Stewart Bryant is the responsible AD. From asmirnov@cisco.com Tue Jun 11 13:20:51 2013 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 1BEE221F99D4 for ; Tue, 11 Jun 2013 13:20:51 -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 Ov2Lei5rJGak for ; Tue, 11 Jun 2013 13:20:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E621F99D0 for ; Tue, 11 Jun 2013 13:20:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5BKKeec003354; Tue, 11 Jun 2013 22:20:40 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5BKK1IG029335; Tue, 11 Jun 2013 22:20:16 +0200 (CEST) Message-ID: <51B78671.6020405@cisco.com> Date: Tue, 11 Jun 2013 22:20:01 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Tue, 11 Jun 2013 20:20:51 -0000 Hi Acee, I also support bis revision - couple of points not covered in the original document may negatively impact interoperability between different implementations. Regarding sequence numbers - if I understand wording in 'bis' revision correctly, sender is using single incrementing sequence number counter independent of packet type and receiver is using one sequence number per packet type, correct? I am asking because RFC 4222 recommends to sort packets into two classes (i.e. not as many classes as there are packet types), so mentioning it may be somewhat confusing. Anton On 06/11/2013 01:35 PM, Acee Lindem wrote: > Thank Michael - Does anyone else support this work? I think it will help > ensure compatibility between implementations. I would have expected at > least those who submitted the corrected errata to support the draft. > Thanks, > Acee > > On 6/6/13 1:12 PM, "Michael Barnes" wrote: > >> I agree these are good changes. Acee, please move forward with this draft. >> >> Thanks, >> Michael >> >> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>> There have been a couple errata filed on RFC 6505 (authors copied). As >>> a service to the >>> OSPF community and in an effort to ensure interoperable OSPFv3 >>> authentication >>> trailer implementations, I have produced a BIS draft. The changes are >>> listed in >>> section 1.2: >>> >>> 1.2. Summary of Changes from RFC 6506 >>> >>> This document includes the following changes from RFC 6506 >>> [RFC6506]: >>> >>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >>> (LLS) block checksum calculation is omitted when an OSPFv3 >>> authentication is used. The LLS block is included in the >>> authentication digest calculation and computation of a checksum >>> is unneccessary. Clarification of this issue was raised in an >>> errata. >>> >>> 2. Section 4.5 includes a correction to the key preparation to use >>> the protocol specific key (Ks) rather than the key (K) as the >>> initial key (Ko). This problem was also raised in an errata. >>> >>> 3. Section 4.5 also includes a discussion of the choice of key >>> length to be the hash length (L) rather than the block size (B). >>> The discussion of this choice was included to clarify an issue >>> raised in a rejected errata. >>> >>> 4. Section 4.1 indicates that sequence number checking is dependent >>> on OSPFv3 packet type in order to account for packet >>> prioritization as specified in [RFC4222]. This was an omission >>> from RFC 6506. >>> >>> >>> I would like to quickly move this to an OSPF WG document and begin the >>> review process. I'm now soliciting feedback on OSPF WG adoption. >>> >>> Thanks, >>> Acee >>> >>> >>> On May 9, 2013, at 1:43 PM, >>> wrote: >>> >>>> >>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt >>>> has been successfully submitted by Manav Bhatia and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-acee-ospf-rfc6506bis >>>> Revision: 01 >>>> Title: Supporting Authentication Trailer for OSPFv3 >>>> Creation date: 2013-05-09 >>>> Group: Individual Submission >>>> Number of pages: 25 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-acee-ospf-rfc6506bis-01 >>>> >>>> Abstract: >>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>> for authenticating protocol packets. This behavior is different >>>> from >>>> authentication mechanisms present in other routing protocols >>>> (OSPFv2, >>>> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >>>> Information Protocol Next Generation (RIPng)). In some >>>> environments, >>>> it has been found that IPsec is difficult to configure and maintain >>>> and thus cannot be used. This document defines an alternative >>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 >>>> does >>>> not only depend upon IPsec for authentication. This document >>>> obsoletes RFC 6506. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From prvs=687437bc8c=acee.lindem@ericsson.com Tue Jun 11 14:29:36 2013 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 8947821F9A17 for ; Tue, 11 Jun 2013 14:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 r4D5c2XMe4gH for ; Tue, 11 Jun 2013 14:29:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F114C21F8904 for ; Tue, 11 Jun 2013 14:29:29 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-1c-51b796b98cde Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.23.05617.9B697B15; Tue, 11 Jun 2013 23:29:29 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 17:29:28 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGpkxN/iAgAATZoA= Date: Tue, 11 Jun 2013 21:29:27 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47164224@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> <51B78671.6020405@cisco.com> In-Reply-To: <51B78671.6020405@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6001D101529AB1489C7FF0DC3411D611@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXSPn+7OadsDDd5NULRo2cZq0XLvHrsD k8eU3xtZPZYs+ckUwBTFbZOUWFIWnJmep2+XwJ2x+Pst5oLX2hW9UxezNzC+V+pi5OSQEDCR eP/xKTuELSZx4d56ti5GLg4hgaOMEtc27WKCcJYzSvzbeZ0VpIpNQEfi+aN/zCC2iICaxOa7 n8DizALKEo+7VrOB2MICIRLnWk4ydjFyANWESpzZVAthWkk8/l0DUsEioCqxv6WRCcTmFfCW aLm9CqxTSCBL4syytSwgNqeApsTj3dvBbEag276fWsMEsUlc4taT+UwQNwtILNlznhnCFpV4 +fgfK4StLLHkyX4WiHodiQW7P7FB2NYSh59eY4awtSWWLXzNDHGDoMTJmU9YJjCKz0KyYhaS 9llI2mchaZ+FpH0BI+sqRo7S4tSy3HQjw02MwJg6JsHmuINxwSfLQ4zSHCxK4rw6vIsDhQTS E0tSs1NTC1KL4otKc1KLDzEycXCCCC6pBkZhZ4mn58s/bVXd7MDx4qrfFP4jlpqf91kw8K5h /L+mRbTLyS7hxqHeyHlHXDyy3v2u/F/9jHfhh0uyjR8/lnwuMLlbcLg9vON6XAbr1dtMTjq6 KV/n+XnvFNnzXs/Bo7z0Q/antssSx694RS6RnmE/dS//ufw+r8g6l9xuHd/fgmG3z8xS51Ri Kc5INNRiLipOBABcJY7JfAIAAA== Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Tue, 11 Jun 2013 21:29:36 -0000 Hi Anton,=20 I am glad you asked.=20 On Jun 11, 2013, at 4:20 PM, Anton Smirnov wrote: > Hi Acee, > I also support bis revision - couple of points not covered in the origi= nal document may negatively impact interoperability between different imple= mentations. >=20 > Regarding sequence numbers - if I understand wording in 'bis' revision = correctly, sender is using single incrementing sequence number counter inde= pendent of packet type and receiver is using one sequence number per packet= type, correct? I am asking because RFC 4222 recommends to sort packets int= o two classes (i.e. not as many classes as there are packet types), so ment= ioning it may be somewhat confusing. Excerpt from section 1.2: 4. Section 4.1 and 4.6 indicate that sequence number checking is dependent on OSPFv3 packet type in order to account for packet prioritization as specified in [RFC4222]. This was an omission from RFC 6506. Thanks, Acee >=20 > Anton >=20 >=20 > On 06/11/2013 01:35 PM, Acee Lindem wrote: >> Thank Michael - Does anyone else support this work? I think it will help >> ensure compatibility between implementations. I would have expected at >> least those who submitted the corrected errata to support the draft. >> Thanks, >> Acee >>=20 >> On 6/6/13 1:12 PM, "Michael Barnes" wrote: >>=20 >>> I agree these are good changes. Acee, please move forward with this dra= ft. >>>=20 >>> Thanks, >>> Michael >>>=20 >>> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>>> There have been a couple errata filed on RFC 6505 (authors copied). As >>>> a service to the >>>> OSPF community and in an effort to ensure interoperable OSPFv3 >>>> authentication >>>> trailer implementations, I have produced a BIS draft. The changes are >>>> listed in >>>> section 1.2: >>>>=20 >>>> 1.2. Summary of Changes from RFC 6506 >>>>=20 >>>> This document includes the following changes from RFC 6506 >>>> [RFC6506]: >>>>=20 >>>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signallin= g >>>> (LLS) block checksum calculation is omitted when an OSPFv3 >>>> authentication is used. The LLS block is included in the >>>> authentication digest calculation and computation of a checksu= m >>>> is unneccessary. Clarification of this issue was raised in an >>>> errata. >>>>=20 >>>> 2. Section 4.5 includes a correction to the key preparation to us= e >>>> the protocol specific key (Ks) rather than the key (K) as the >>>> initial key (Ko). This problem was also raised in an errata. >>>>=20 >>>> 3. Section 4.5 also includes a discussion of the choice of key >>>> length to be the hash length (L) rather than the block size (B= ). >>>> The discussion of this choice was included to clarify an issue >>>> raised in a rejected errata. >>>>=20 >>>> 4. Section 4.1 indicates that sequence number checking is depende= nt >>>> on OSPFv3 packet type in order to account for packet >>>> prioritization as specified in [RFC4222]. This was an omissio= n >>>> from RFC 6506. >>>>=20 >>>>=20 >>>> I would like to quickly move this to an OSPF WG document and begin the >>>> review process. I'm now soliciting feedback on OSPF WG adoption. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>> On May 9, 2013, at 1:43 PM, >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt >>>>> has been successfully submitted by Manav Bhatia and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-acee-ospf-rfc6506bis >>>>> Revision: 01 >>>>> Title: Supporting Authentication Trailer for OSPFv3 >>>>> Creation date: 2013-05-09 >>>>> Group: Individual Submission >>>>> Number of pages: 25 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>>>>=20 >>>>> Abstract: >>>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>>> for authenticating protocol packets. This behavior is different >>>>> from >>>>> authentication mechanisms present in other routing protocols >>>>> (OSPFv2, >>>>> Intermediate System to Intermediate System (IS-IS), RIP, and Routi= ng >>>>> Information Protocol Next Generation (RIPng)). In some >>>>> environments, >>>>> it has been found that IPsec is difficult to configure and maintai= n >>>>> and thus cannot be used. This document defines an alternative >>>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 >>>>> does >>>>> not only depend upon IPsec for authentication. This document >>>>> obsoletes RFC 6506. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=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 prvs=887540fea2=acee.lindem@ericsson.com Wed Jun 12 13:59:23 2013 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 6191111E80F0 for ; Wed, 12 Jun 2013 13:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 PY-01-ofDFBU for ; Wed, 12 Jun 2013 13:59:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 942D611E810E for ; Wed, 12 Jun 2013 13:59:16 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-cb-51b8e12315cf Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D0.44.05617.321E8B15; Wed, 12 Jun 2013 22:59:16 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 16:59:15 -0400 From: Acee Lindem To: "Marek Karasek (mkarasek)" Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGpkwxEsAgAAE6QCAAZbKAA== Date: Wed, 12 Jun 2013 20:59:15 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47165A94@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47163A7A@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <626919D23DD9184EBAFCCEB25647D543@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPlK7Kwx2BBpu/8Fj8/NLJatFy7x67 A5PHlN8bWT2WLPnJFMAUxW2TlFhSFpyZnqdvl8Cd8fjEa5aC31YVD+ZeY2pgvKPfxcjJISFg ItG0cDsbhC0mceHeeiCbi0NI4CijxLUbzcwQznJGiR+HnzOBVLEJ6Eg8f/QPKMHBISJgLDHr DitImFlAWeJx12qwQcICIRLnWk4yQpSESpzZVAsSFhFwkth06gIjiM0ioCrx7O9sdhCbV8Bb Yv3bPhYQm1PAR+Lig2NgcUage76fWsMEMV5c4taT+UwQdwpILNlznhnCFpV4+fgf2AmiAnoS bcfOsEPElSWWPNnPAtGrI7Fg9yc2CNtaYtaHNqiTtSWWLXzNDHGDoMTJmU9YJjCKz0KybhaS 9llI2mchaZ+FpH0BI+sqRo7S4tSy3HQjw02MwKg6JsHmuINxwSfLQ4zSHCxK4ryxqjsChQTS E0tSs1NTC1KL4otKc1KLDzEycXCCCC6pBkbmLOnDLdfS2ufmOLuf9lbyfLfNdcl7jyddk1fO vl2y6pO12GSGb5d84q7Pufjym+y3nG97xeIfWgU3tv14ssGpoLk75EbbJcWoo9xy13Z2X9XV UWfk85kd5TQzMEZc/WPPu6Ubl/99PftW+gMllq+lMU1v57PufxV3SvD06/sfmQNfhZ6Qu2ap xFKckWioxVxUnAgAfbRKX30CAAA= Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Wed, 12 Jun 2013 20:59:23 -0000 Hi Marek, I thought about this and I think we need to modify the behavior in transition mode for this to provide a smooth transition. An OSPFv3 router in transition mode needs to "be conservative in what it sends and liberal in what it accepts". Hence, in transition mode, the router would accept packet with and without an authentication trailer but would not include the authentication trailer in this mode. If you don't do it this way, you'll have a deployment window problem since routers in transition mode will still be sending packets that won't be accepted by routers that have not yet been converted - they'll be dropped due to checksum errors. If you don't include the authentication header, you just need to: 1. Convert all the nodes in the routing domain to OSPFv3 authentication transition mode. There will be no timing dependencies. 2. Convert routers to send at the authentication trailer in any order.=20 Agree?=20 Thanks, Acee=20 =20 On 6/11/13 6:43 AM, "Acee Lindem" wrote: >Hi Marek,=20 >I've thought about it and this would be compatible with the rest of the >draft. It would be useful if incremental deployment is a concern. I have >no objection to adding this. Any other opinions? > >Thanks, >Acee >On Jun 11, 2013, at 9:26 AM, Marek Karasek (mkarasek) wrote: > >> Hi Acee, >>=20 >> I support bis version as well. >>=20 >> I have one more suggestion though for this paragraph: >>=20 >> In support of uninterrupted deployment, an OSPFv3 router implementing >> this specification MAY implement a transition mode where it includes >> the Authentication Trailer in transmitted packets but does not verify >> this information in received packets. This is provided as a >> transition aid for networks in the process of migrating to the >> authentication mechanism described in this specification. >>=20 >>=20 >> Can it be explicitly added how to work with checksums in the transition >>(or deployment) mode? I suggest adding: >>=20 >> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3 >>header checksum and LLS data block checksum is computed and written in >>the packets. >> - For packets received in deployment mode which include an OSPFv3 >>Authentication Trailer, OSPFv3 header checksum verification MUST be >>omitted. >> - For packets received in deployment mode which do not include an >>OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data block >>checksum are verified. >>=20 >>=20 >> Thanks marek >>=20 >>=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >>Acee Lindem >> Sent: Tuesday, June 11, 2013 1:35 PM >> To: Michael Barnes (mjbarnes); ospf@ietf.org >> Subject: Re: [OSPF] New Version Notification for >>draft-acee-ospf-rfc6506bis-01.txt >>=20 >> Thank Michael - Does anyone else support this work? I think it will >>help ensure compatibility between implementations. I would have expected >>at least those who submitted the corrected errata to support the draft. >> Thanks, >> Acee >>=20 >> On 6/6/13 1:12 PM, "Michael Barnes" wrote: >>=20 >>> I agree these are good changes. Acee, please move forward with this >>>draft. >>>=20 >>> Thanks, >>> Michael >>>=20 >>> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>>> There have been a couple errata filed on RFC 6505 (authors copied). >>>> As a service to the OSPF community and in an effort to ensure >>>> interoperable OSPFv3 authentication trailer implementations, I have >>>> produced a BIS draft. The changes are listed in section 1.2: >>>>=20 >>>> 1.2. Summary of Changes from RFC 6506 >>>>=20 >>>> This document includes the following changes from RFC 6506 >>>> [RFC6506]: >>>>=20 >>>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >>>> (LLS) block checksum calculation is omitted when an OSPFv3 >>>> authentication is used. The LLS block is included in the >>>> authentication digest calculation and computation of a checksum >>>> is unneccessary. Clarification of this issue was raised in an >>>> errata. >>>>=20 >>>> 2. Section 4.5 includes a correction to the key preparation to use >>>> the protocol specific key (Ks) rather than the key (K) as the >>>> initial key (Ko). This problem was also raised in an errata. >>>>=20 >>>> 3. Section 4.5 also includes a discussion of the choice of key >>>> length to be the hash length (L) rather than the block size >>>>(B). >>>> The discussion of this choice was included to clarify an issue >>>> raised in a rejected errata. >>>>=20 >>>> 4. Section 4.1 indicates that sequence number checking is >>>>dependent >>>> on OSPFv3 packet type in order to account for packet >>>> prioritization as specified in [RFC4222]. This was an omission >>>> from RFC 6506. >>>>=20 >>>>=20 >>>> I would like to quickly move this to an OSPF WG document and begin >>>> the review process. I'm now soliciting feedback on OSPF WG adoption. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>> On May 9, 2013, at 1:43 PM, >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been >>>>> successfully submitted by Manav Bhatia and posted to the IETF >>>>> repository. >>>>>=20 >>>>> Filename: draft-acee-ospf-rfc6506bis >>>>> Revision: 01 >>>>> Title: Supporting Authentication Trailer for OSPFv3 >>>>> Creation date: 2013-05-09 >>>>> Group: Individual Submission >>>>> Number of pages: 25 >>>>> URL: =20 >>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>>>> Status: =20 >>>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>>> Htmlized: =20 >>>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>>> Diff: =20 >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>>>>=20 >>>>> Abstract: >>>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>>> for authenticating protocol packets. This behavior is different >>>>> from >>>>> authentication mechanisms present in other routing protocols >>>>> (OSPFv2, >>>>> Intermediate System to Intermediate System (IS-IS), RIP, and >>>>>Routing >>>>> Information Protocol Next Generation (RIPng)). In some >>>>> environments, >>>>> it has been found that IPsec is difficult to configure and maintain >>>>> and thus cannot be used. This document defines an alternative >>>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 >>>>> does >>>>> not only depend upon IPsec for authentication. This document >>>>> obsoletes RFC 6506. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=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 > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From mkarasek@cisco.com Wed Jun 12 14:23:33 2013 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 774A821E8094 for ; Wed, 12 Jun 2013 14:23:33 -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 XFHDU13804Rk for ; Wed, 12 Jun 2013 14:23:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CB87221E805D for ; Wed, 12 Jun 2013 14:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9154; q=dns/txt; s=iport; t=1371072208; x=1372281808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/QTSga4NuQnA/W2eqW5IOcKOw0Ai94/6/aehf1Gz850=; b=kNB8zN49NXYXX6sVVmMQ0t+f0oep9U7/X2vWzayCaVyoItBCBRD6PKkn q9YGgIkCfqIgu8kEhaahPyyk/KDmeNCDODw2xL3NPbbjNAA2+WlGpXGge 3dvbdpZA5hyKu16yTMp7MhXhN1yTnmwzC3X0oWQrEWxBvh46ILnRZ/RCN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHrluFGtJXG+/2dsb2JhbABagwkwQwa+SoEBFnSCIwEBAQQBAQE3NAkCDAQCAQgRBAEBAQoLCQkHJwsUCQgCBA4FCAELh3oHBbsejxIxBwYEgnVhA5NuhHuQGYMPgic X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="219107065" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jun 2013 21:23:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLNQuG031396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 21:23:26 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.81]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 16:23:26 -0500 From: "Marek Karasek (mkarasek)" To: Acee Lindem Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfPs+Y9akuG1Uyjl0ojg1ZQuZkwfPcwgABdAACAAgwPgP//rOaA Date: Wed, 12 Jun 2013 21:23:25 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47163A7A@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47165A94@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47165A94@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.25.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Wed, 12 Jun 2013 21:23:33 -0000 Hi Acee, Please see %MK in your lines: -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Wednesday, June 12, 2013 10:59 PM To: Marek Karasek (mkarasek) Cc: ospf@ietf.org Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis= -01.txt Hi Marek, I thought about this and I think we need to modify the behavior in transiti= on mode for this to provide a smooth transition. An OSPFv3 router in transi= tion mode needs to "be conservative in what it sends and liberal in what it= accepts". Hence, in transition mode, the router would accept packet with a= nd without an authentication trailer but would not include the authenticati= on trailer in this mode. If you don't do it this way, you'll have a deploym= ent window problem since routers in transition mode will still be sending p= ackets that won't be accepted by routers that have not yet been converted -= they'll be dropped due to checksum errors.=20 %MK they should not drop packets, checksums are populated, see: >> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3=20 >>header checksum and LLS data block checksum is computed and written in=20 >>the packets. If you don't include the authentication header, you just need to: 1. Convert all the nodes in the routing domain to OSPFv3 authenticat= ion transition mode. There will be no timing dependencies. 2. Convert routers to send at the authentication trailer in any orde= r.=20 %MK what happens if router with AT receives packet without AT (from router = doing transition)? I think it will be dropped. That's the issue. My idea (already tested) was: 1) start deployment in "transition" mode. Transitioning routers will add AT. 1a) Routers without AT will ignore AT and verify CRC as usual. Note CRC is = computed so packet is OK for them.=20 1b) Routers running AT transition or AT will verify AT. Router running AT t= ransition will not drop if problem with AT, they will verify also CRC and i= f OK packet is accepted. 2) Say all or most of routers are in "transition" mode. There will be show = command option to verify that AT works OK since AT is verified, but packet = is not dropped if AT NOK or not present. AT incompatible neighbors may be p= ointed out and fixed. 3) If all looks OK, you can move routers to standard AT mode at any time. T= hey will stop computed CRC, it's not needed anymore. Thanks marek Agree?=20 Thanks, Acee=20 =20 On 6/11/13 6:43 AM, "Acee Lindem" wrote: >Hi Marek, >I've thought about it and this would be compatible with the rest of the=20 >draft. It would be useful if incremental deployment is a concern. I=20 >have no objection to adding this. Any other opinions? > >Thanks, >Acee >On Jun 11, 2013, at 9:26 AM, Marek Karasek (mkarasek) wrote: > >> Hi Acee, >>=20 >> I support bis version as well. >>=20 >> I have one more suggestion though for this paragraph: >>=20 >> In support of uninterrupted deployment, an OSPFv3 router implementing >> this specification MAY implement a transition mode where it includes >> the Authentication Trailer in transmitted packets but does not verify >> this information in received packets. This is provided as a >> transition aid for networks in the process of migrating to the >> authentication mechanism described in this specification. >>=20 >>=20 >> Can it be explicitly added how to work with checksums in the=20 >>transition (or deployment) mode? I suggest adding: >>=20 >> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3=20 >>header checksum and LLS data block checksum is computed and written in=20 >>the packets. >> - For packets received in deployment mode which include an OSPFv3=20 >>Authentication Trailer, OSPFv3 header checksum verification MUST be=20 >>omitted. >> - For packets received in deployment mode which do not include an >>OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data=20 >>block checksum are verified. >>=20 >>=20 >> Thanks marek >>=20 >>=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 >>Of Acee Lindem >> Sent: Tuesday, June 11, 2013 1:35 PM >> To: Michael Barnes (mjbarnes); ospf@ietf.org >> Subject: Re: [OSPF] New Version Notification for=20 >>draft-acee-ospf-rfc6506bis-01.txt >>=20 >> Thank Michael - Does anyone else support this work? I think it will=20 >>help ensure compatibility between implementations. I would have=20 >>expected at least those who submitted the corrected errata to support the= draft. >> Thanks, >> Acee >>=20 >> On 6/6/13 1:12 PM, "Michael Barnes" wrote: >>=20 >>> I agree these are good changes. Acee, please move forward with this=20 >>>draft. >>>=20 >>> Thanks, >>> Michael >>>=20 >>> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>>> There have been a couple errata filed on RFC 6505 (authors copied). >>>> As a service to the OSPF community and in an effort to ensure=20 >>>> interoperable OSPFv3 authentication trailer implementations, I=20 >>>> have produced a BIS draft. The changes are listed in section 1.2: >>>>=20 >>>> 1.2. Summary of Changes from RFC 6506 >>>>=20 >>>> This document includes the following changes from RFC 6506 >>>> [RFC6506]: >>>>=20 >>>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >>>> (LLS) block checksum calculation is omitted when an OSPFv3 >>>> authentication is used. The LLS block is included in the >>>> authentication digest calculation and computation of a checksum >>>> is unneccessary. Clarification of this issue was raised in an >>>> errata. >>>>=20 >>>> 2. Section 4.5 includes a correction to the key preparation to use >>>> the protocol specific key (Ks) rather than the key (K) as the >>>> initial key (Ko). This problem was also raised in an errata. >>>>=20 >>>> 3. Section 4.5 also includes a discussion of the choice of key >>>> length to be the hash length (L) rather than the block size=20 >>>>(B). >>>> The discussion of this choice was included to clarify an issue >>>> raised in a rejected errata. >>>>=20 >>>> 4. Section 4.1 indicates that sequence number checking is=20 >>>>dependent >>>> on OSPFv3 packet type in order to account for packet >>>> prioritization as specified in [RFC4222]. This was an omission >>>> from RFC 6506. >>>>=20 >>>>=20 >>>> I would like to quickly move this to an OSPF WG document and begin=20 >>>> the review process. I'm now soliciting feedback on OSPF WG adoption. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>> On May 9, 2013, at 1:43 PM, >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been=20 >>>>> successfully submitted by Manav Bhatia and posted to the IETF=20 >>>>> repository. >>>>>=20 >>>>> Filename: draft-acee-ospf-rfc6506bis >>>>> Revision: 01 >>>>> Title: Supporting Authentication Trailer for OSPFv3 >>>>> Creation date: 2013-05-09 >>>>> Group: Individual Submission >>>>> Number of pages: 25 >>>>> URL: =20 >>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>>>> Status: =20 >>>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>>> Htmlized: =20 >>>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>>> Diff: =20 >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>>>>=20 >>>>> Abstract: >>>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>>> for authenticating protocol packets. This behavior is different =20 >>>>>from >>>>> authentication mechanisms present in other routing protocols =20 >>>>>(OSPFv2, >>>>> Intermediate System to Intermediate System (IS-IS), RIP, and=20 >>>>>Routing >>>>> Information Protocol Next Generation (RIPng)). In some =20 >>>>>environments, >>>>> it has been found that IPsec is difficult to configure and maintain >>>>> and thus cannot be used. This document defines an alternative >>>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 =20 >>>>>does >>>>> not only depend upon IPsec for authentication. This document >>>>> obsoletes RFC 6506. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=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 > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From prvs=0875f449bf=acee.lindem@ericsson.com Wed Jun 12 14:39:12 2013 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 8DDE221E80ED for ; Wed, 12 Jun 2013 14:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 KtSvuoCG5DJf for ; Wed, 12 Jun 2013 14:39:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D1C5221E80E5 for ; Wed, 12 Jun 2013 14:39:06 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-1f-51b8ea7636c7 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3F.B6.05617.67AE8B15; Wed, 12 Jun 2013 23:39:03 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 17:39:02 -0400 From: Acee Lindem To: "Marek Karasek (mkarasek)" Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGpkwxEsAgAAE6QCAAZbKAIAAfAWAgAAEXIA= Date: Wed, 12 Jun 2013 21:39:01 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47165B89@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE47163A7A@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47165A94@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EED2E378569B945AE24DA3E1D95AAA3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPoG75qx2BBseWilr8/NLJatFy7x67 A5PHlN8bWT2WLPnJFMAUxW2TlFhSFpyZnqdvl8CdseL/LraCqb4V3ybdYm1g3GfXxcjJISFg IrHm2XN2CFtM4sK99WxdjFwcQgJHGSX2T1nFDOEsZ5T4fX0/C0gVm4COxPNH/4ASHBwiAsYS s+6wgoSZBZQlHnetZgOxhQVCJM61nGSEKAmVOLOpFiQsIuAn8XDhMyYQm0VAVWLutRtgrbwC 3hK3pyxlBrGFBC4wStyaVQBicwr4Stx50A8WZwS67fupNUwQq8Qlbj2ZzwRxs4DEkj3nmSFs UYmXj/+xQtjKEkueQFzMDHTxgt2f2CBsa4mNTVsYIWxtiWULXzND3CAocXLmE5YJjOKzkKyY haR9FpL2WUjaZyFpX8DIuoqRo7Q4tSw33chwEyMwqo5JsDnuYFzwyfIQozQHi5I4b6zqjkAh gfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBceWrNEUzFSXndMOaF39uliwO/Dln8rbyBV3u a1UyVWf8E1olHnR5wwX9208Upvntzk2InWep1yGzN7bjxrTu73pqKwX4FWQSmz9kBhx/znx2 +o5pX+7tnvJL7t9Ko5r+PQtmrb569ryrwI3Z85pL5dQchRLfeaj++OvW3RRVynSVXfsX7+3J iUosxRmJhlrMRcWJAEIFC9h9AgAA Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.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: Wed, 12 Jun 2013 21:39:12 -0000 Hi Marek, On Jun 12, 2013, at 5:23 PM, Marek Karasek (mkarasek) wrote: > Hi Acee, >=20 > Please see %MK in your lines: >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Wednesday, June 12, 2013 10:59 PM > To: Marek Karasek (mkarasek) > Cc: ospf@ietf.org > Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506b= is-01.txt >=20 > Hi Marek, > I thought about this and I think we need to modify the behavior in transi= tion mode for this to provide a smooth transition. An OSPFv3 router in tran= sition mode needs to "be conservative in what it sends and liberal in what = it accepts". Hence, in transition mode, the router would accept packet with= and without an authentication trailer but would not include the authentica= tion trailer in this mode. If you don't do it this way, you'll have a deplo= yment window problem since routers in transition mode will still be sending= packets that won't be accepted by routers that have not yet been converted= - they'll be dropped due to checksum errors.=20 >=20 > %MK they should not drop packets, checksums are populated, see: >>> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3=20 >>> header checksum and LLS data block checksum is computed and written in= =20 >>> the packets. Ok - I thought of this alternative but missed that you included it. At firs= t, I thought the above would be simpler since it only modified the receivin= g side.=20 >=20 > If you don't include the authentication header, you just need to: >=20 > 1. Convert all the nodes in the routing domain to OSPFv3 authentica= tion transition mode. There will be no timing dependencies. > 2. Convert routers to send at the authentication trailer in any ord= er.=20 >=20 > %MK what happens if router with AT receives packet without AT (from route= r doing transition)? I think it will be dropped. That's the issue. Yes - I can see how taking doing both authentication and checksums could be= simpler on multi-access links. We can stay with this.=20 Thanks, Acee=20 >=20 > My idea (already tested) was: > 1) start deployment in "transition" mode. > Transitioning routers will add AT. > 1a) Routers without AT will ignore AT and verify CRC as usual. Note CRC i= s computed so packet is OK for them.=20 > 1b) Routers running AT transition or AT will verify AT. Router running AT= transition will not drop if problem with AT, they will verify also CRC and= if OK packet is accepted. > 2) Say all or most of routers are in "transition" mode. There will be sho= w command option to verify that AT works OK since AT is verified, but packe= t is not dropped if AT NOK or not present. AT incompatible neighbors may be= pointed out and fixed. > 3) If all looks OK, you can move routers to standard AT mode at any time.= They will stop computed CRC, it's not needed anymore. >=20 > Thanks marek >=20 >=20 > Agree?=20 >=20 > Thanks, > Acee=20 >=20 >=20 > On 6/11/13 6:43 AM, "Acee Lindem" wrote: >=20 >> Hi Marek, >> I've thought about it and this would be compatible with the rest of the= =20 >> draft. It would be useful if incremental deployment is a concern. I=20 >> have no objection to adding this. Any other opinions? >>=20 >> Thanks, >> Acee >> On Jun 11, 2013, at 9:26 AM, Marek Karasek (mkarasek) wrote: >>=20 >>> Hi Acee, >>>=20 >>> I support bis version as well. >>>=20 >>> I have one more suggestion though for this paragraph: >>>=20 >>> In support of uninterrupted deployment, an OSPFv3 router implementing >>> this specification MAY implement a transition mode where it includes >>> the Authentication Trailer in transmitted packets but does not verify >>> this information in received packets. This is provided as a >>> transition aid for networks in the process of migrating to the >>> authentication mechanism described in this specification. >>>=20 >>>=20 >>> Can it be explicitly added how to work with checksums in the=20 >>> transition (or deployment) mode? I suggest adding: >>>=20 >>> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3=20 >>> header checksum and LLS data block checksum is computed and written in= =20 >>> the packets. >>> - For packets received in deployment mode which include an OSPFv3=20 >>> Authentication Trailer, OSPFv3 header checksum verification MUST be=20 >>> omitted. >>> - For packets received in deployment mode which do not include an >>> OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data=20 >>> block checksum are verified. >>>=20 >>>=20 >>> Thanks marek >>>=20 >>>=20 >>> -----Original Message----- >>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 >>> Of Acee Lindem >>> Sent: Tuesday, June 11, 2013 1:35 PM >>> To: Michael Barnes (mjbarnes); ospf@ietf.org >>> Subject: Re: [OSPF] New Version Notification for=20 >>> draft-acee-ospf-rfc6506bis-01.txt >>>=20 >>> Thank Michael - Does anyone else support this work? I think it will=20 >>> help ensure compatibility between implementations. I would have=20 >>> expected at least those who submitted the corrected errata to support t= he draft. >>> Thanks, >>> Acee >>>=20 >>> On 6/6/13 1:12 PM, "Michael Barnes" wrote: >>>=20 >>>> I agree these are good changes. Acee, please move forward with this=20 >>>> draft. >>>>=20 >>>> Thanks, >>>> Michael >>>>=20 >>>> On 05/09/2013 11:03 AM, Acee Lindem wrote: >>>>> There have been a couple errata filed on RFC 6505 (authors copied). >>>>> As a service to the OSPF community and in an effort to ensure=20 >>>>> interoperable OSPFv3 authentication trailer implementations, I=20 >>>>> have produced a BIS draft. The changes are listed in section 1.2: >>>>>=20 >>>>> 1.2. Summary of Changes from RFC 6506 >>>>>=20 >>>>> This document includes the following changes from RFC 6506 >>>>> [RFC6506]: >>>>>=20 >>>>> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >>>>> (LLS) block checksum calculation is omitted when an OSPFv3 >>>>> authentication is used. The LLS block is included in the >>>>> authentication digest calculation and computation of a checksum >>>>> is unneccessary. Clarification of this issue was raised in an >>>>> errata. >>>>>=20 >>>>> 2. Section 4.5 includes a correction to the key preparation to use >>>>> the protocol specific key (Ks) rather than the key (K) as the >>>>> initial key (Ko). This problem was also raised in an errata. >>>>>=20 >>>>> 3. Section 4.5 also includes a discussion of the choice of key >>>>> length to be the hash length (L) rather than the block size=20 >>>>> (B). >>>>> The discussion of this choice was included to clarify an issue >>>>> raised in a rejected errata. >>>>>=20 >>>>> 4. Section 4.1 indicates that sequence number checking is=20 >>>>> dependent >>>>> on OSPFv3 packet type in order to account for packet >>>>> prioritization as specified in [RFC4222]. This was an omission >>>>> from RFC 6506. >>>>>=20 >>>>>=20 >>>>> I would like to quickly move this to an OSPF WG document and begin=20 >>>>> the review process. I'm now soliciting feedback on OSPF WG adoption. >>>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>>=20 >>>>> On May 9, 2013, at 1:43 PM, >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been=20 >>>>>> successfully submitted by Manav Bhatia and posted to the IETF=20 >>>>>> repository. >>>>>>=20 >>>>>> Filename: draft-acee-ospf-rfc6506bis >>>>>> Revision: 01 >>>>>> Title: Supporting Authentication Trailer for OSPFv3 >>>>>> Creation date: 2013-05-09 >>>>>> Group: Individual Submission >>>>>> Number of pages: 25 >>>>>> URL: =20 >>>>>> http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.tx= t >>>>>> Status: =20 >>>>>> http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>>>>> Htmlized: =20 >>>>>> http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>>>>> Diff: =20 >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-01 >>>>>>=20 >>>>>> Abstract: >>>>>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>>>>> for authenticating protocol packets. This behavior is different =20 >>>>>> from >>>>>> authentication mechanisms present in other routing protocols =20 >>>>>> (OSPFv2, >>>>>> Intermediate System to Intermediate System (IS-IS), RIP, and=20 >>>>>> Routing >>>>>> Information Protocol Next Generation (RIPng)). In some =20 >>>>>> environments, >>>>>> it has been found that IPsec is difficult to configure and maintain >>>>>> and thus cannot be used. This document defines an alternative >>>>>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 =20 >>>>>> does >>>>>> not only depend upon IPsec for authentication. This document >>>>>> obsoletes RFC 6506. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=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 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 From curtis@ipv6.occnc.com Sat Jun 15 08:47:29 2013 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 B243821F9DDE for ; Sat, 15 Jun 2013 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 ecBCtcdXchI5 for ; Sat, 15 Jun 2013 08:47:24 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0C21F9DD6 for ; Sat, 15 Jun 2013 08:47:24 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5FFk6g1043117; Sat, 15 Jun 2013 11:46:08 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201306151546.r5FFk6g1043117@gateway1.orleans.occnc.com> To: draft-ietf-ospf-te-metric-extensions@tools.ietf.org From: Curtis Villamizar Date: Sat, 15 Jun 2013 11:46:06 -0400 Cc: ospf@ietf.org Subject: [OSPF] draft-ietf-ospf-te-metric-extensions-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:47:29 -0000 Spence et al, Since this is a working group document, I am copying the WG mailing list. The document has come a long way. There are a few changes that need to be made. Most significant is addressing the topic of network stability and oscillations. You need to do one of the following. Pick one. 1. Explain conditions under which stability can be insured and conditions under which oscillations are likely or certain to occur. This is not that hard. 2. Change the SHOULD NOT to MUST NOT in the statement about not including queuing contributions to delay, jitter, and loss. If you do this, jitter and loss are useless and should be removed entirely from the set of extensions. So far you have indicated that you don't want the first option but are unwilling to go with the second option. As is, the document is unacceptable. When submitting you should check the nits prodused by idnits. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 572 has weird spacing: '...figured upper...' Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4203' is mentioned on line 189, but not defined == Missing Reference: 'RFC4206' is mentioned on line 500, but not defined == Missing Reference: 'RFC5329' is mentioned on line 653, but not defined == Unused Reference: 'RFC2328' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 679, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 0 comments (--). Run idnits with the --verbose option for more detailed information about the items above. As a matter of style, when defining a TLV, the description of the individual fields should not be subsections. These should be done as a hanging indent list. If there is no way to do that in the word template, then that is one more reason to abandon use of word and convert the document to xml2rfc format. In the long run if you ever want to make this an RFC it will probably be a lot less work to convert now. Normally the ascii art for the TLV layout is followed by the hanging indent list. The list has brief descriptions of what each field represents. Futher discussion of how the fields are used together in the TLV follow the list (not in the list and therefore not indented). You will end up changing this at some point so it might as well be done now. See RFC3630 or RFC5105 or any RFC defining TLVs for examples of how to format this. As you mentioned, there is a mix of min/max and low/high and it should all become low/high. So much for nits. On to substative comments. This statement does not adequately address stability and oscillation: While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Thus, queuing delays and/or loss SHOULD NOT be included in any dynamic delay measurement. For links, such as Forwarding Adjacencies, care must be taken that measurement of the associated delay avoids significant queuing delay; that could be accomplished in a variety of ways, including either by measuring with a traffic class that experiences minimal queuing or by summing the measured link delays of the components of the link's path. The above sentences appear within somewhat of a run-on paragraph in "1. Introduction". The only other mention of queu* is in "7. Network Stability and Announcement Periodicity" in the following short paragraph. Furthermore, it is RECOMMENDED that any underlying performance measurement mechanisms not include any significant buffer delay, any significant buffer induced delay variation, or any significant loss due to buffer overflow or due to active queue management. What I suggest you do is move this block of text from "Introduction" to "Network Stability and Announcement Periodicity" and leave a forward reference in "Introduction". OLD: Note that the mechanisms described in this document only disseminate performance information. The methods for initially gathering that performance information, such as [RFC6375], or acting on it once it is distributed are outside the scope of this document. Example mechanisms to measure latency, delay variation, and loss in an MPLS network are given in [RFC6374]. While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Thus, queuing delays and/or loss SHOULD NOT be included in any dynamic delay measurement. For links, such as Forwarding Adjacencies, care must be taken that measurement of the associated delay avoids significant queuing delay; that could be accomplished in a variety of ways, including either by measuring with a traffic class that experiences minimal queuing or by summing the measured link delays of the components of the link's path. NEW: The mechanisms described in this document only disseminate performance information. The methods for initially gathering that performance information, such as [RFC6375], or acting on it once it is distributed are outside the scope of this document. Example mechanisms to measure latency, delay variation, and loss in an MPLS network are given in [RFC6374]. While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Refer to "Section 7. Network Stability and Announcement Periodicity" for precautions to insure network stability. Since buffer and queue mean the same thing and the preferred term is queue, the existing paragraph should be reworded and the text removed from "Introduction", also reworded should be included. Further precautions should be included. OLD: Furthermore, it is RECOMMENDED that any underlying performance measurement mechanisms not include any significant buffer delay, any significant buffer induced delay variation, or any significant loss due to buffer overflow or due to active queue management. NEW: Any underlying performance measurement mechanisms SHOULD NOT include any significant queuing delay, any significant queuing induced delay variation, or any significant loss due to queue overflow or due to active queue management. For links over an underlying layer which may already introduce some queue effects, such as pseudowire or PSC LSP advertised as Forwarding Adjacencies (FAs), care must be taken that measurement of the associated delay avoids significant queuing delay. This could be accomplished in a variety of ways, including either measuring with a traffic class that experiences minimal queuing or by summing the measured link delays of the segments of the FA's path if these are known to exclude queue effects. If any queuing induced delay, jitter, or loss are included, then precautions MUST be taken to insure stability and avoid oscillations. Situations in which oscillations are minimized include those where the traffic over which delay and loss measurements are made constitute a small minoring of traffic flow and where the traffic over which delay and loss measurements are made is able to preempt other traffic to obtain a better path. In such a situation, movement of traffic may be transient and mostly in response to major events such as network faults. If the level of the traffic over which delay and loss measurements are made significantly affects the measurements, then oscillations are insured. This is particularly true for jitter, where measurements even over a highly preferred minority of traffic will be affected by the levels of traffic. Use of long measurement and traffic engineering timers will not eliminate the oscillation, but will increase the period of the continuous oscillation cycle. This practice will not minimize the measured parameter on the path taken by the majority of traffic. The tendency will be to concentrate traffic on a set of links advertised at a given time as the best path. When timers expire, the concentration of traffic will move away from their existing overutilized paths onto a different, previously underutilized paths, overutilizing these. This type of route oscillation over a long period is known as route slosh. Route slosh is disruptive and results in poor end-user network performance, with continuous change in delay and with regular brief periods of packet reordering. There are situations where even a relatively long timer interval, such as intervals of a minute or more, will reduce but not prevent oscillations. An example is a lower layer low probability of loss that results in an intermittent switch to protection resources with an automatic reversion to working path when loss falls below a given fault threshold. This is characteristic of insufficient hysteresis at a lower layer. Fixed announcement and LSP reroute timers are somewhat analogous to a fixed low pass filter in electronics. Low frequency oscillations are unaffected by the filter. The compatibility section is too brief and is inadequate. Note: no period at the end of the sentence. OLD: As per (RFC3630), unrecognized TLVs should be silently ignored NEW: If a non-compliant LSR does not advertise delay, jitter, or loss for its adjacencies, then LER can either choose to assume default (high) values, or avoid creating paths using these LSR for LSP that have delay, jitter, or loss requirements. As per (RFC3630), unrecognized TLVs should be silently ignored. A non-conformant LER should be unaffected by the presence of the TLVs defined in this document. Note: possible errata to RFC3630. The statement is "Unrecognized types are ignored." and is made twice in RFC3630. This statement should use RFC2119 wording and IMO should be replaced by "Unrecognized types MUST be ignored." These comments apply to the draft-previdi-isis-te-metric-extensions as well as to draft-ietf-ospf-te-metric-extensions when isis-te-metric-extensions is updated. Curtis From abdussalambaryun@gmail.com Sun Jun 16 12:40:35 2013 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 615DC21F994A for ; Sun, 16 Jun 2013 12:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 P2hRQ4YP-uH6 for ; Sun, 16 Jun 2013 12:40:35 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 01BC021F98AC for ; Sun, 16 Jun 2013 12:40:34 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so2179623pac.12 for ; Sun, 16 Jun 2013 12:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sVkAd+0IVST2Jbt6I0Q+VFIfwxG4eYLeVaYKSlBixdE=; b=Q7hpdCQRD1Qa+1V/bB/LuZhq1att1rFa+aFNPEEAI/WdHnx9aCuNtFZu+fSUIadTJy vv1Dm0lF6o2mPijr/o2UNJymn4zDYL2hQkvh2imwin0SGMAmKGZMnnZS/k5CYqK3gMsL eN+SaGUIhqh7Pif+Vcm//Wjp4kHDMwn9S1l9EgmNDaaDcLR6jQw869vR26aOpWvbmhCf 0fa30aW6y9GEIvW/0soHwIev5ZieGz6uDlegWGqyYvO+gNWoO3jH2zRSzPdW11mWOcyd vwaQRq06RqAp6PrvPNDRQJPiXnXTZyAe1ycJg5zXCDOsdIApm8odxV32QBUPpwgf2tyV HNsg== MIME-Version: 1.0 X-Received: by 10.68.203.103 with SMTP id kp7mr2489786pbc.165.1371411634649; Sun, 16 Jun 2013 12:40:34 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Sun, 16 Jun 2013 12:40:34 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> Date: Sun, 16 Jun 2013 21:40:34 +0200 Message-ID: From: Abdussalam Baryun To: OSPF List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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: Sun, 16 Jun 2013 19:40:35 -0000 The following were first of my comments on the document and I got some answers; http://www.ietf.org/mail-archive/web/manet/current/msg15401.html http://www.ietf.org/mail-archive/web/manet/current/msg15418.html Answers http://www.ietf.org/mail-archive/web/manet/current/msg15408.html http://www.ietf.org/mail-archive/web/ietf/current/msg79931.html As a request from the chair and for wg information, after I got to be subscribed in this WG. Thanking you, AB From prvs=8879887a5f=acee.lindem@ericsson.com Sun Jun 16 14:57:43 2013 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 CEE8E21F9B00 for ; Sun, 16 Jun 2013 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 hjbqk7TORgKO for ; Sun, 16 Jun 2013 14:57:38 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4B86121F9AD1 for ; Sun, 16 Jun 2013 14:57:38 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-5f-51be34d1b95a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 54.38.05617.1D43EB15; Sun, 16 Jun 2013 23:57:37 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Sun, 16 Jun 2013 17:57:36 -0400 From: Acee Lindem To: Abdussalam Baryun Thread-Topic: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC Thread-Index: AQHOaslhL0C56oHghEe07f/spCHwWZk5Jn+A Date: Sun, 16 Jun 2013 21:57:36 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4717B686@eusaamb101.ericsson.se> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6301CF9828CFD045BDD139BDA8D959F1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonXPeiyb5Ag4VTpC2+3WhlsvjRc4PZ 4tWzfjaLlnv32B1YPFZ9mcDssXPWXXaPJUt+Mnms2LySMYAlitsmKbGkLDgzPU/fLoE7Y8G9 GUwF6zgq1p9Ob2D8zdbFyMkhIWAi8fXWLhYIW0ziwr31QHEuDiGBo4wSD1+2QTnLGSWenZ3I BFLFJqAj8fzRP2YQW0TASGLp7y1gk5gFsiX+fZvKBNIgLDCfUWLd+0WMII6IwAJGif9LG5hg OubOOgTWwSKgKjFpyimwOK+At8Tz3p1gcSGBw0wSP37VgticAoESk1pfsoLYjED3fT+1hgli m7jErSfzmSDuFpBYsuc8M4QtKvHy8T9WCFtZYsmT/SwQ9ToSC3Z/grrUWmLDtm9QtrbEsoWv mSFuEJQ4OfMJywRG8VlIVsxC0j4LSfssJO2zkLQvYGRdxchRWpxalptuZLiJERiDxyTYHHcw LvhkeYhRmoNFSZz3/aldgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4QQSXVAPj8rzNzUfTPDjr NRb1t18Niwr9oVQf+KxsicfTv9NONrRe+J6+9bb/o1vMT3+VH5Dzt/rtMYH1g/uXwmM96xdJ TN/7L71anOP73t8nfgVzTmda6PNHvaMkOl3ppPRrJvUpE8LWa1Z9LZ2R//zeY4toxyO+in28 R5sWLN23007woIzy3r7mrY25SizFGYmGWsxFxYkAPCjK6JQCAAA= Cc: OSPF List Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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: Sun, 16 Jun 2013 21:57:43 -0000 Abdu,=20 This is an extension to an existing OSPF specification (FRC 5614). Even if = it weren't, the OSPF WG has no mandate to adhere to RFC 5444 or any other M= ANET WG documents. Since this work was previously done in the OSPF WG, ther= e is no reason to even consider bringing it to MANET (although we welcome t= heir review).=20 Thanks, Acee =20 On Jun 16, 2013, at 3:40 PM, Abdussalam Baryun wrote: > The following were first of my comments on the document and I got some an= swers; >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg15401.html > http://www.ietf.org/mail-archive/web/manet/current/msg15418.html >=20 > Answers > http://www.ietf.org/mail-archive/web/manet/current/msg15408.html > http://www.ietf.org/mail-archive/web/ietf/current/msg79931.html >=20 > As a request from the chair and for wg information, after I got to be > subscribed in this WG. Thanking you, >=20 > AB > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From anandmkr@cisco.com Sun Jun 16 21:15:07 2013 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 94C2821F9990 for ; Sun, 16 Jun 2013 21:15:07 -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 KNr4fGGYtwRy for ; Sun, 16 Jun 2013 21:15:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B4E6921F994A for ; Sun, 16 Jun 2013 21:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3012; q=dns/txt; s=iport; t=1371442502; x=1372652102; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZBU2ht5yWm7i8h+KkRdEE24Epl0J5oN2A5ucmmJ0XOo=; b=TvovmU/EjKubcGBX4tyf2104jWflB6wMzKH93xnJmXe2X631UgmduI1q bM6m7Fx0TIWVRdvVIVAEjgTOnn9v5LLDi5HSV27fLBq+jjYa/u5Ij7zY0 FlU1wh1tiWkC5cnpwt5ivr4t0lasuWXtsd++pJYJfNR/qL8mBiAcnl4iZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAOKMvlGtJXHA/2dsb2JhbABagwkxQwa+UoEEFm0HgiUBBDo4BQISAQgiFEIlAgQOBQgBiAUHBbdfjg+BBzEHgn9hA5NvhHuQGoMPgWhA X-IronPort-AV: E=Sophos;i="4.87,878,1363132800"; d="scan'208";a="223538090" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2013 04:15:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5H4F1Mk027225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 04:15:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.242]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 16 Jun 2013 23:15:01 -0500 From: "Madhukar Anand (anandmkr)" To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt Thread-Index: AQHOaxB6veIaFt2heUyHZvceKkKAA5k5KtqA Date: Mon, 17 Jun 2013 04:14:59 +0000 Message-ID: <60816F26681B6440A1552440352BAE941DD5E294@xmb-aln-x05.cisco.com> In-Reply-To: <20130617040919.17495.50463.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.148.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F5C9B6A32F8E246A29F703BF61174CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Madhukar Anand Subject: Re: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.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, 17 Jun 2013 04:15:07 -0000 Thanks for all the feedback. We have made 3 modifications modifications to the previous draft: (1) In the introduction, we have added OSPFv3 Autoconfig as another use-case: Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of [OSPFV3-AUTOCONFIG]). These requirements can be easily met by implementing the proposal here. (2) In 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. Routers that recognize this new extended options will set the value of the neighbor dead interval to the value specified in the LLS block TLV, but only if BOTH the HELLO and dead interval are set to zero in the OSPF HELLO packet. (3) We have also summarized the discussion section and the relation of this proposal w.r.t. BFD. It is possible to use Bidirectional Forwarding Detection (BFD) [RFC 5880] to alleviate some of the concerns in the use-cases identified above. Relying entirely on BFD without OSPF HELLOs is not a possibility given that OSPF HELLOs are still used for discovery of neighbors. The BFD approach has its own shortcomings such as limited cross-vendor and cross-platform support and also performance implications, especially with increasing scale requirements. In any case, BFD can be made to work in conjunction with the proposal in this document to achieve the best possible network performance. It is intended that the proposal for asymmetric hold timer would work independent of BFD deployment considerations, and could also help in new applications where it may be desirable to support asymmetric and possibly dynamic dead interval values (e.g., OSPFv3 Auto-Configuration, [OSPFV3-AUTOCONFIG]). Thanks, Madhukar On 6/16/13 9:09 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-madhukar-ospf-agr-asymmetric-01.txt >has been successfully submitted by Madhukar Anand and posted to the >IETF repository. > >Filename: draft-madhukar-ospf-agr-asymmetric >Revision: 01 >Title: Asymmetric OSPF Hold Timer >Creation date: 2013-06-16 >Group: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-madhukar-ospf-agr-asymmetric-01. >txt >Status: =20 >http://datatracker.ietf.org/doc/draft-madhukar-ospf-agr-asymmetric >Htmlized: =20 >http://tools.ietf.org/html/draft-madhukar-ospf-agr-asymmetric-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-madhukar-ospf-agr-asymmetric-01 > >Abstract: > Current OSPF standard requires that the HELLO/Dead interval be > symmetric on either side of the link in order to maintain adjacency. > There are many scenarios in which this may not be desirable. This > memo describes a technique to allow OSPF adjacency to be maintained > with asymmetric values of the OSPF Dead interval. > > > =20 > =20 > > >The IETF Secretariat > From abdussalambaryun@gmail.com Mon Jun 17 02:56:33 2013 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 643AE21F9B90 for ; Mon, 17 Jun 2013 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ZPt0LhsRf26e for ; Mon, 17 Jun 2013 02:56:29 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0F21F9814 for ; Mon, 17 Jun 2013 02:56:22 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so2593900pdi.25 for ; Mon, 17 Jun 2013 02:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZRVvWzeyDaF3cI6+NlpISM+QJY3hmlcT/T/LnpI/5VY=; b=zC8OmzVMMRJ09KFpkSaLOMq80DUwG8jpxGiKywDroOOrgvefShIn4YG9Z95KC2Wl0o de8zSYCR83W3SecLfXQR79C4uXi8ErQfIHNNXZ2DGp3Vsevg8+kLrEmg2Re0Jn+8vG8y /IRz0gAapBlFdXEBu0BI3YyV5V+pySSNqXpN7R3A5n3SJOd7nYUuo5ljEHC7YMNu142B ICo5HtH36QYVNpey8Tl9hyIii6eoqHfpWg25+E6liyzeaXj4F32VfbmaYVFvX0iEfxkn +vTDfXw4S+U85iKwHPbyLsL9PTXHzmgbo09kjGGud/cC5oacru3R1jV7+S2RQCBkZaWP CLnA== MIME-Version: 1.0 X-Received: by 10.68.203.103 with SMTP id kp7mr4455106pbc.165.1371462982240; Mon, 17 Jun 2013 02:56:22 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Mon, 17 Jun 2013 02:56:22 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4717B686@eusaamb101.ericsson.se> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4717B686@eusaamb101.ericsson.se> Date: Mon, 17 Jun 2013 10:56:22 +0100 Message-ID: From: Abdussalam Baryun To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b15af5de113d204df569bb2 Cc: OSPF List Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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, 17 Jun 2013 09:56:33 -0000 --047d7b15af5de113d204df569bb2 Content-Type: text/plain; charset=ISO-8859-1 Hi Acee, I distinguish between the word MANET and OSPF they are not the same thing but all are for same IETF. One is a network and the other is a protocol, so the network is more general than a protocol in terms of applicability. The RFC5614 is specification related to the MANET network, but I know that this WG done the work, but I always think it is important to have joint work between related WGs participants not separation within IETF. All RFCs are for the same IETF so they should be related some how. Abdu On Sun, Jun 16, 2013 at 10:57 PM, Acee Lindem wrote: > Abdu, > > This is an extension to an existing OSPF specification (FRC 5614). Even if > it weren't, the OSPF WG has no mandate to adhere to RFC 5444 or any other > MANET WG documents. Since this work was previously done in the OSPF WG, > there is no reason to even consider bringing it to MANET (although we > welcome their review). > > Thanks, > Acee > > On Jun 16, 2013, at 3:40 PM, Abdussalam Baryun wrote: > > > The following were first of my comments on the document and I got some > answers; > > > > http://www.ietf.org/mail-archive/web/manet/current/msg15401.html > > http://www.ietf.org/mail-archive/web/manet/current/msg15418.html > > > > Answers > > http://www.ietf.org/mail-archive/web/manet/current/msg15408.html > > http://www.ietf.org/mail-archive/web/ietf/current/msg79931.html > > > > As a request from the chair and for wg information, after I got to be > > subscribed in this WG. Thanking you, > > > > AB > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > --047d7b15af5de113d204df569bb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Acee,
=A0
I distinguish betwee= n the word MANET and OSPF they are not the same thing but all are for same= =A0IETF. One is a network and the other is a protocol, so the network is mo= re general than a protocol in terms of applicability. The RFC5614 is specif= ication related to the MANET network, but I know that this WG done the work= , but I always think it is important to have joint work between related WGs= participants not separation within IETF. All RFCs are for the same IETF so= they should be related some how.
=A0
Abdu


On Sun, Jun 16, 2013 at 10:57 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:
Abdu,

This is an extension to an existing OSPF specification (FRC 5614). Even if = it weren't, the OSPF WG has no mandate to adhere to RFC 5444 or any oth= er MANET WG documents. Since this work was previously done in the OSPF WG, = there is no reason to even consider bringing it to MANET (although we welco= me their review).

Thanks,
Acee

On Jun 16, 2013, at 3:40 PM, Abdussalam Baryun wrote:

> The following were first of my comments on the document and I got some= answers;
>
> http://www.ietf.org/mail-archive/web/manet/current= /msg15401.html
> http://www.ietf.org/mail-archive/web/manet/current= /msg15418.html
>
> Answers
> http://www.ietf.org/mail-archive/web/manet/current= /msg15408.html
> http://www.ietf.org/mail-archive/web/ietf/current/m= sg79931.html
>
> As a request from the chair and for wg information, after I got to be<= br> > subscribed in this WG. Thanking you,
>
> AB
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf


--047d7b15af5de113d204df569bb2-- From prvs=4880a952b0=acee.lindem@ericsson.com Mon Jun 17 05:36:15 2013 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 4275C21F859A for ; Mon, 17 Jun 2013 05:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 G8gbXDhszaYR for ; Mon, 17 Jun 2013 05:36:09 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98521F88EA for ; Mon, 17 Jun 2013 05:36:09 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-6c-51bf02b8934f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 36.A1.05617.8B20FB15; Mon, 17 Jun 2013 14:36:08 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 08:36:07 -0400 From: Acee Lindem To: Abdussalam Baryun Thread-Topic: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC Thread-Index: AQHOaslhL0C56oHghEe07f/spCHwWZk5Jn+AgADI1ACAACyhAA== Date: Mon, 17 Jun 2013 12:36:07 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4717D1AB@eusaamb101.ericsson.se> References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4717B686@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4717D1ABeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPrO4Opv2BBi96ZS2+3WhlsvjRc4PZ 4tWzfjaLlnv32B1YPFZ9mcDssXPWXXaPJUt+Mnms2LySMYAlitsmKbGkLDgzPU/fLoE748uq eywFU80qZn3fztrAeEW3i5GTQ0LARGLTrnZ2CFtM4sK99WxdjFwcQgJHGSV+9W1hgnCWM0rc uHGDFaSKTUBH4vmjf8wgtoiAkcTS31vAOpgFJjJKLFg7jxXEERaYzyix7v0iRhBHRGABo8T/ pQ1MEC1OEk9W/gZbyCKgKnHhYBNYnFfAW2Lpm6lQ+84wSyybdBGsiFMgUGLHl0tg+xiBLvx+ ag1YA7OAuMStJ/OZIC4XkFiy5zwzhC0q8fLxP1YIW1liyZP9LBD1+RLzJp9ig1gmKHFy5hOW CYyis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPIbqtZZomb+LFVnNAkaOVYwcpcWp ZbnpRoabGIERekyCzXEH44JPlocYpTlYlMR535/aFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD E0RwSTUwdknbVm4KnrZR2Vkz4eGb+qbT224J7urtXnh0fvhyhWe7l/kvVRV5tdrt182kOsno 7f612bfmLTrnf+nG/UaRc26Vd1YqZc2TNnE/l+mQeOuB+u4ZmkGSu97JS0Urvru6+2e/0yHv tSxODZw3f4vHfUiwWd4dEfJf2oe7/GVtmtMdB57romrHlFiKMxINtZiLihMBdyvq/aMCAAA= Cc: OSPF List , Stan Podin Subject: Re: [OSPF] [manet] Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC 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, 17 Jun 2013 12:36:15 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4717D1ABeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abdu, On Jun 17, 2013, at 5:56 AM, Abdussalam Baryun wrote: Hi Acee, I distinguish between the word MANET and OSPF they are not the same thing b= ut all are for same IETF. One is a network and the other is a protocol, so = the network is more general than a protocol in terms of applicability. Agreed. The RFC5614 is specification related to the MANET network, but I know that = this WG done the work, but I always think it is important to have joint wor= k between related WGs participants not separation within IETF. All RFCs are= for the same IETF so they should be related some how. At a high level, I agree and this is why we have an IETF Last Call. In prac= tice, the alignment of multiple WGs with overlapping charters is a difficul= t problem. However, in this specific case, I don't agree that it is desirab= le for there to be alignment. RFC 5444 is about packet formats and encoding= for protocols in the MANET WG (as opposed to MANET networks in the broader= sense). Hence, I don't see that it has applicability here and it may not e= ven have applicability to MANET protocols that predate it. Thanks, Acee Abdu On Sun, Jun 16, 2013 at 10:57 PM, Acee Lindem > wrote: Abdu, This is an extension to an existing OSPF specification (FRC 5614). Even if = it weren't, the OSPF WG has no mandate to adhere to RFC 5444 or any other M= ANET WG documents. Since this work was previously done in the OSPF WG, ther= e is no reason to even consider bringing it to MANET (although we welcome t= heir review). Thanks, Acee On Jun 16, 2013, at 3:40 PM, Abdussalam Baryun wrote: > The following were first of my comments on the document and I got some an= swers; > > http://www.ietf.org/mail-archive/web/manet/current/msg15401.html > http://www.ietf.org/mail-archive/web/manet/current/msg15418.html > > Answers > http://www.ietf.org/mail-archive/web/manet/current/msg15408.html > http://www.ietf.org/mail-archive/web/ietf/current/msg79931.html > > As a request from the chair and for wg information, after I got to be > subscribed in this WG. Thanking you, > > AB > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --_000_94A203EA12AECE4BA92D42DBFFE0AE4717D1ABeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <470ED58C1E26F94DBADC8F57DA0877D4@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi Abdu, 

On Jun 17, 2013, at 5:56 AM, Abdussalam Baryun wrote:

Hi Acee,
 
I distinguish between the word MANET and OSPF they are not the same th= ing but all are for same IETF. One is a network and the other is a pro= tocol, so the network is more general than a protocol in terms of applicabi= lity.

Agreed. 

The RFC5614 is specification related to the MANET network, but I know = that this WG done the work, but I always think it is important to have join= t work between related WGs participants not separation within IETF. All RFC= s are for the same IETF so they should be related some how.

At a high level, I agree and this is why we have an IETF Last Call. In= practice, the alignment of multiple WGs with overlapping charters is a dif= ficult problem. However, in this specific case, I don't agree that it is de= sirable for there to be alignment. RFC 5444 is about packet formats and encoding for protocols in the MANET W= G (as opposed to MANET networks in the broader sense). Hence, I don't see t= hat it has applicability here and it may not even have applicability to MAN= ET protocols that predate it. 

Thanks,
Acee


 
Abdu


On Sun, Jun 16, 2013 at 10:57 PM, Acee Lindem <acee.lind= em@ericsson.com> wrote:
Abdu,

This is an extension to an existing OSPF specification (FRC 5614). Even if = it weren't, the OSPF WG has no mandate to adhere to RFC 5444 or any other M= ANET WG documents. Since this work was previously done in the OSPF WG, ther= e is no reason to even consider bringing it to MANET (although we welcome their review).

Thanks,
Acee

On Jun 16, 2013, at 3:40 PM, Abdussalam Baryun wrote:

> The following were first of my comments on the document and I got some= answers;
>
> http://www.ietf.org/mail-archive/web/manet/current/msg15401.html
> http://www.ietf.org/mail-archive/web/manet/current/msg15418.html
>
> Answers
> http://www.ietf.org/mail-archive/web/manet/current/msg15408.html
> http://www.ietf.org/mail-archive/web/ietf/current/msg79931.html
>
> As a request from the chair and for wg information, after I got to be<= br> > subscribed in this WG. Thanking you,
>
> AB
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf



--_000_94A203EA12AECE4BA92D42DBFFE0AE4717D1ABeusaamb101ericsso_-- From rbharath@juniper.net Tue Jun 18 04:56:33 2013 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 13B4821F9BD1 for ; Tue, 18 Jun 2013 04:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 oo0tH+S-SiN6 for ; Tue, 18 Jun 2013 04:56:26 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73921F8F24 for ; Tue, 18 Jun 2013 04:56:22 -0700 (PDT) Received: from mail162-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 11:56:22 +0000 Received: from mail162-ch1 (localhost [127.0.0.1]) by mail162-ch1-R.bigfish.com (Postfix) with ESMTP id 17A9F2C10D7 for ; Tue, 18 Jun 2013 11:56:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail162-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbharath@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail162-ch1 (localhost.localdomain [127.0.0.1]) by mail162-ch1 (MessageSwitch) id 13715565801726_8806; Tue, 18 Jun 2013 11:56:20 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail162-ch1.bigfish.com (Postfix) with ESMTP id F2260C0060 for ; Tue, 18 Jun 2013 11:56:19 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 11:56:19 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Jun 2013 04:56:18 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 18 Jun 2013 04:56:18 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 18 Jun 2013 05:08:17 -0700 Received: from mail177-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 11:56:17 +0000 Received: from mail177-tx2 (localhost [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id 3670E20170 for ; Tue, 18 Jun 2013 11:56:17 +0000 (UTC) Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1371556574240772_12511; Tue, 18 Jun 2013 11:56:14 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.247]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 368C360055 for ; Tue, 18 Jun 2013 11:56:14 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 11:56:13 +0000 Received: from BN1PRD0512MB620.namprd05.prod.outlook.com ([169.254.16.70]) by BN1PRD0512HT004.namprd05.prod.outlook.com ([10.255.193.37]) with mapi id 14.16.0324.000; Tue, 18 Jun 2013 11:56:13 +0000 From: Bharath R To: "OSPF@ietf.org" Thread-Topic: Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. Thread-Index: Ac5sGnznNwBh+oLtRnGrauEoRknkhQ== Date: Tue, 18 Jun 2013 11:56:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.83] Content-Type: multipart/alternative; boundary="_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81146BN1PRD0512MB620_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Dileep Singh Subject: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. 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, 18 Jun 2013 11:59:19 -0000 --_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81146BN1PRD0512MB620_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please consider the scenario: R1(DR) R2(BDR) | I1 I2 | | | |______________________ | | | I3 | R3(DR-Other) Here: R1 is the DR. R2 is the BDR R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. Following are the is the set of operations and a sequence of events: 1. Interface I1 is disabled. So, DR connectivity is lost to the rest o= f the network. 2. R2(The current BDR) detects the DR-down. a. Declares itself the DR. b. Declares BDR as NULL. c. Sends out a Hello with DR as I2 interface address, and BDR as 0.0.0= .0 3. R3(DR-Other) receives Hello from R2. As per, section 9.2 of RFC 2328: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Triggers a NeighborChange event, which in-turn results in a DR electi= on at R3. Please note that at this time R3 has not yet detected R1 down. Now result of DR-election at R3: DR: R1 BDR: 0.0.0.0 Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with= R2(the new DR). Of course, on detection of DR down at R3, R3 will elect R2 as DR and = then again transition to ExStart, to Exchange to Full with R2. Can you please let me know: * Is it right to trigger the NeighborChange event at R3 ? * Is this transition from FULL to 2-WAY is expected? * Can DR-Others flap adjacency with BDR if DR down detection happens= later than reception of new Hello from the new DR? * Intuitively, it may seem desirable to continue to be adjacent to a = neighbor as long as it is still DR or BDR. Is this a fair call? Please correct me if I have missed out something. Thanks and Regards, Bharath R. --_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81146BN1PRD0512MB620_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
Please consider the scenario:
 
R1(DR)          &nbs= p;            &= nbsp;           &nbs= p;        R2(BDR)    = ;             <= /div>
|  I1          = ;            &n= bsp;            = ;            I2 = ;  |
|           &n= bsp;            = ;            &n= bsp;            = ;           |
|______________________ |
           &nbs= p;            &= nbsp;       |
           &nbs= p;            &= nbsp;       |  I3    = ;             <= /div>
           &nbs= p;            &= nbsp;       |
           &nbs= p;          R3(DR-Other)
 
Here:
R1 is the DR.
R2 is the BDR
R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/B= DR.
 
 
Following are the is the set of operations and a sequence of events:
 
  1. Interface I1 is disabled. So, DR connectivity is lost to the rest of th= e network.
  2. R2(The current BDR) detects the DR-down.
  1. Declares itself the DR.
  2. Declares BDR as NULL.
  3. Sends out= a Hello with DR as I2 interface address, and BDR as 0.0.0.0
  1. R3(DR-Other) receives Hello from R2.
As per, section 9.2 of RFC 2328:
            o = ;  One of the bidirectional neighbors is newly declaring=
            &= nbsp;   itself as either Designated Router or Backup Designated
            &= nbsp;   Router.  This is detected through examination of tha= t
            &= nbsp;   neighbor's Hello Packets.
 
            o = ;  One of the bidirectional neighbors is no longer
            &= nbsp;   declaring itself as Designated Router, or is no longer
            &= nbsp;   declaring itself as Backup Designated Router.  This = is
            &= nbsp;   again detected through examination of that neighbor's
            &= nbsp;   Hello Packets.
 <= /div>
Triggers a NeighborChange e= vent, which in-turn results in a DR election at R3.
Please note that at this time R3 has n= ot yet detected R1 down.
Now result of DR-election at R3:
DR: R1
BDR: 0.0.0.0
Since R2 is no longer the BDR, R3 transit= ions from FULL to 2-WAY with R2(the new DR).
Of course, on detection of DR down at R3,= R3 will elect R2 as DR and then again transition to ExStart, to Exchange t= o Full with R2.
 
Can you please let me know:
  • Is  it right to trigger the NeighborChange event at R3 ?
  • I= s this transition from FULL to 2-WAY  is expected?
  • Can DR-Othe= rs flap adjacency with BDR if DR down detection  happens later than re= ception of new Hello from  the new DR?
  • Intuitively, it may see= m desirable to continue to be adjacent to a neighbor as long as it is still= DR or BDR. Is this a fair call?
 
Please correct me if I have missed out something.
 
 
Thanks and Regards,
Bharath R.
 
 
 
 
 
 --_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81146BN1PRD0512MB620_-- From tanmoycs@gmail.com Tue Jun 18 07:00:43 2013 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 EEF4421F8201 for ; Tue, 18 Jun 2013 07:00:42 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 lFtR5ObdROPc for ; Tue, 18 Jun 2013 07:00:30 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F721F9B16 for ; Tue, 18 Jun 2013 07:00:30 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id n12so5109236oag.29 for ; Tue, 18 Jun 2013 07:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYVaUhaHNtKetiRh4NuevrbThFVUarjoChIT8sZdn9E=; b=EmOeX2lG5WdOhKB+XT9TcHMSHWD8IfhqgC+QLN1Wm9DRE6c+fVfnoDYKtoR/V7JI8j TWFaJ7pwoRT4ZYXe72cBJRpbRzEH5uC7WvhVSXAvEO3XSRyC0zeBdIKoI/AbAKqKxnqd fHqaEfcMRlGK14h3DR7TslVpRQM7kQXF6hGI7Ta5ASGha8WOffmpG6IXKF91ePKy4zNY rpGADOsP0uWfN8q3ghnN4tDQrQ+PKt+wjabGm2OwRlZastu/hmKEkxsNjomwAYGO4FdC SmYZFNKpOBxkYLP0hyphLrS5+Y880RLFQkYFrjLgo3srZXrVAcVqSSLbEd1CcH8x1GBz 2FZg== MIME-Version: 1.0 X-Received: by 10.182.144.231 with SMTP id sp7mr12380418obb.14.1371564029797; Tue, 18 Jun 2013 07:00:29 -0700 (PDT) Received: by 10.182.42.201 with HTTP; Tue, 18 Jun 2013 07:00:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 19:30:29 +0530 Message-ID: From: Tanmoy Kundu To: Bharath R Content-Type: multipart/alternative; boundary=089e0153686cc8704804df6e223a Cc: "OSPF@ietf.org" , Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. 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, 18 Jun 2013 14:00:43 -0000 --089e0153686cc8704804df6e223a Content-Type: text/plain; charset=ISO-8859-1 Hi Bharath, Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", how did R2 sensed that R1 is down ? a. first possible option is dead timer expiry in R2. In that case R3 should also get the expiry soon and till that time the network won't converge. isn't that expected? b. Another option is having BFD session between R1 and R2, hence it comes to know. Why don't we run BFD between all the routers in the network ? As we know in OSPF the DR and BDR is not guaranteed. This typical scenario is due to the DR-other is with priority zero. But when received hello packet from DR, both BDR and DR-Other should reset the dead timer. Even if we consider the link transmission delay and ASIC processing, the dead timer expiry difference between R2 and R3 should not be more than milisecond, isn't it ? - Is it right to trigger the NeighborChange event at R3? - I feel yes, other than few typical scenarios the network will at least not be used, until its converged. If Nbr-chg event is not sent then all DR other feels that DR is still active and the same will be used for forwarding the traffic. If someone in the network sensed that DR/BDR is down, why don't tell others immediately? - Is this transition from FULL to 2-WAY is expected? - As per RFC, DR others should not be FULL with other routers than DR and BDR, hence YES. It is expected. - Can DR-Others flap adjacency with BDR if DR down detection happens later than reception of new Hello from the new DR? - - Intuitively, it may seem desirable to continue to be adjacent to a neighbor as long as it is still DR or BDR. Is this a fair call? - As mentioned above, its not fair to use a disturbed or unsettled network for forwarding. Due to backlink check failure the LAN wont be used for forwarding during SPF. Hence as per me its proper behavior. Thanks, Tanmoy On Tue, Jun 18, 2013 at 5:26 PM, Bharath R wrote: > Hi, > Please consider the scenario: > > R1(DR) R2(BDR) > | I1 I2 | > | | > |______________________ | > | > | I3 > | > R3(DR-Other) > > Here: > R1 is the DR. > R2 is the BDR > R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. > > > Following are the is the set of operations and a sequence of events: > > > 1. Interface I1 is disabled. So, DR connectivity is lost to the rest > of the network. > 2. R2(The current BDR) detects the DR-down. > > > 1. Declares itself the DR. > 2. Declares BDR as NULL. > 3. Sends out a Hello with DR as I2 interface address, and BDR as > 0.0.0.0 > > > 1. R3(DR-Other) receives Hello from R2. > > As per, section 9.2 of RFC 2328: > o One of the bidirectional neighbors is newly declaring > itself as either Designated Router or Backup Designated > Router. This is detected through examination of that > neighbor's Hello Packets. > > o One of the bidirectional neighbors is no longer > declaring itself as Designated Router, or is no longer > declaring itself as Backup Designated Router. This is > again detected through examination of that neighbor's > Hello Packets. > > *Triggers a NeighborChange **e**vent, which in-turn results in a DR > election at R3*. > *Please note that at this time R3 has not yet detected R1 down*. > Now result of DR-election at R3: > DR: R1 > BDR: 0.0.0.0 > Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with > R2(the new DR). > Of course, on detection of DR down at R3, R3 will elect R2 as DR and then > again transition to ExStart, to Exchange to Full with R2. > > Can you please let me know: > > - Is it right to trigger the NeighborChange event at R3 ? > - Is this transition from FULL to 2-WAY is expected? > - Can DR-Others flap adjacency with BDR if DR down detection happens > later than reception of new Hello from the new DR? > - Intuitively, it may seem desirable to continue to be adjacent to a > neighbor as long as it is still DR or BDR. Is this a fair call? > > > Please correct me if I have missed out something. > > > Thanks and Regards, > Bharath R. > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --089e0153686cc8704804df6e223a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bharath,=A0
Few queries. As you mentioned "R2(The current BDR) detects= the DR-down.", how did R2 sensed that R1 is down ?
<= font face=3D"Calibri">=A0 =A0 a. first possi= ble option is dead timer=A0expiry in R2. In that case R3 should also get th= e=A0expiry=A0soon and till that time the network won't converge. isn= 9;t that expected?=A0
=A0 =A0 b. Anoth= er option is having BFD session between R1 and R2, hence it comes to know. = Why don't we run BFD between all the routers in the network ? As we kno= w in OSPF the DR and BDR is not=A0guaranteed.=A0

This typ= ical scenario is due to the DR-other is with priority zero. But when receiv= ed hello packet from DR, both BDR and DR-Other should reset the dead timer.= Even if we consider the link transmission delay and ASIC processing, the d= ead timer expiry difference between R2 and R3 should not be more than milis= econd, isn't it ?=A0


  • Is=A0 it right to trigger the NeighborChange= event at R3? - I feel yes, other than few typical scenarios the network wi= ll at least not be used, until its converged. If Nbr-chg event is not sent = then all DR other feels that DR is still active and the same will be used f= or forwarding the traffic. If someone in the network sensed that DR/BDR is = down, why don't tell others immediately?=A0
  • Is this transition from FULL to 2-WAY=A0 is = expected? - As per RFC, DR others should not be FULL with other routers tha= n DR and BDR, hence YES. It is expected.=A0
  • Can DR-Others flap adjacency with BDR if DR down detection=A0 happens later= than reception of new Hello from=A0 the new DR? -=A0
  • Intuitively, it may seem desirable to continue to be adjacent= to a neighbor as long as it is still DR or BDR. Is this a fair call? - As = mentioned above, its not fair to use a disturbed or unsettled network for f= orwarding. Due to backlink check failure the LAN wont be used for forwardin= g during SPF. Hence as per me its proper behavior.=A0


Thanks,
Tanmoy



On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juniper.net= > wrote:
Hi,
Please consider the scenario:
=A0
R1(DR)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 R2(BDR)= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
|=A0 I1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 I2=A0=A0 |
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
|______________________ |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 I3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 R3(DR-= Other)
=A0
Here:
R1 is the DR.
R2 is the BDR
R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/B= DR.
=A0
=A0
Following are the is the set of operations and a sequence of events:
=A0
  1. Interface I1 is disabled. So, DR connectivity is lost to the rest of th= e network.
  2. R2(The current BDR) detects the DR-down.
  1. Declares itself the DR.
  2. Declares BDR as NULL.
  3. Sends out= a Hello with DR as I2 interface address, and BDR as 0.0.0.0
  1. R3(DR-Other) receives Hello from R2.
As per, section 9.2 of RFC 2328:
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 One of the bidirectional neighbors is newl= y declaring
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 itself as either Designated Router or = Backup Designated
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Router.=A0 This is detected through ex= amination of that
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 neighbor's Hello Packets.
=A0
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 One of the bidirectional neighbors is no l= onger
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 declaring itself as Designated Router,= or is no longer
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 declaring itself as Backup Designated = Router.=A0 This is
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 again detected through examination of = that neighbor's
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hello Packets.
=A0
Triggers a NeighborChange e<= b>vent, which in-turn results in a DR election at R3.
Please note that at this time R3 has no= t yet detected R1 down.
Now result of DR-election at R3:
DR: R1
BDR: 0.0.0.0
Since R2 is no longer the BDR, R3 transiti= ons from FULL to 2-WAY with R2(the new DR).
Of course, on detection of DR down at R3, = R3 will elect R2 as DR and then again transition to ExStart, to Exchange to= Full with R2.
=A0
Can you please let me know:
  • Is=A0 it right to trigger the NeighborChange event at R3 ?
  • Is t= his transition from FULL to 2-WAY=A0 is expected?
  • Can DR-Others fla= p adjacency with BDR if DR down detection=A0 happens later than reception o= f new Hello from=A0 the new DR?
  • Intuitively, it may seem desirable to continue to be adjacent to a neig= hbor as long as it is still DR or BDR. Is this a fair call?
=A0
Please correct me if I have missed out something.
=A0
=A0
Thanks and Regards,
Bharath R.
=A0
=A0
=A0
=A0
=A0

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


--089e0153686cc8704804df6e223a-- From rbharath@juniper.net Tue Jun 18 08:58:45 2013 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 7DF8C21F9B6A for ; Tue, 18 Jun 2013 08:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 nboB36IYEH01 for ; Tue, 18 Jun 2013 08:58:39 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6665F21E8054 for ; Tue, 18 Jun 2013 08:58:39 -0700 (PDT) Received: from mail35-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 15:58:38 +0000 Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id 5F7B54E02C4 for ; Tue, 18 Jun 2013 15:58:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic85fh4015I179cIzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hz8dhz8275ch1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail35-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbharath@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1371571116110980_18860; Tue, 18 Jun 2013 15:58:36 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.240]) by mail35-co9.bigfish.com (Postfix) with ESMTP id 1831D320073 for ; Tue, 18 Jun 2013 15:58:36 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 15:58:35 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Jun 2013 08:58:34 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 18 Jun 2013 08:58:34 -0700 Received: from DB8EHSOBE024.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 18 Jun 2013 09:02:06 -0700 Received: from mail125-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 15:58:31 +0000 Received: from mail125-db8 (localhost [127.0.0.1]) by mail125-db8-R.bigfish.com (Postfix) with ESMTP id 054213402DA for ; Tue, 18 Jun 2013 15:58:31 +0000 (UTC) Received: from mail125-db8 (localhost.localdomain [127.0.0.1]) by mail125-db8 (MessageSwitch) id 1371571108508737_15188; Tue, 18 Jun 2013 15:58:28 +0000 (UTC) Received: from DB8EHSMHS023.bigfish.com (unknown [10.174.8.236]) by mail125-db8.bigfish.com (Postfix) with ESMTP id 71407160049; Tue, 18 Jun 2013 15:58:28 +0000 (UTC) Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by DB8EHSMHS023.bigfish.com (10.174.4.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Jun 2013 15:58:27 +0000 Received: from BN1PRD0512MB620.namprd05.prod.outlook.com ([169.254.16.70]) by BN1PRD0512HT003.namprd05.prod.outlook.com ([10.255.193.36]) with mapi id 14.16.0324.000; Tue, 18 Jun 2013 15:58:16 +0000 From: Bharath R To: Tanmoy Kundu Thread-Topic: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. Thread-Index: AQHObC0C41RYLKFrTEaZ1XtgO25hy5k7l4bg Date: Tue, 18 Jun 2013 15:58:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.83] Content-Type: multipart/alternative; boundary="_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81239BN1PRD0512MB620_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "OSPF@ietf.org" , Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. 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, 18 Jun 2013 15:58:45 -0000 --_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81239BN1PRD0512MB620_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tanmoy, Thank you for your quick response. Let me give a few clarifications: Under the below mentioned scenario, we would definitely expect a network co= nvergence delay. But, here, the question is regarding the adjacency flap between DR-Other an= d BDR on DR interface down. If adjacency is anyway going to flap between DR -Other and BDR under some scenarios(It is definitely possible that in a network some routers detect e= vents faster than the others), then is there a significant advantage that we derive from having a BDR? Regarding NeighborChange Event: Sorry If I was not clear, I totally agree that NeighborChange Event should be triggered after DR fail= is detected. But, the question really is should the neighbor Change event be triggered w= hen R2(new DR ) sent a new Hello. Please note that NeighborChange event I am referring to is in response to = the Hello as received from the Neighbor and not a result of our DR calculat= ion. So, If a Neighbor was previously declaring itself a BDR and is now declarin= g itself a DR(to both of which we are expected to be adjacent), should the = NeighborChange event still be triggered? And I don't think having DR-priority non-zero in DR-Others would have made = any difference to the above scenario. R2 instead of declaring BDR NULL would have declared some other router as B= DR(considering a more generic LAN case), and DR other would have still flapped the adjacency with the new DR(R2) since R2 was BDR= before and is no longer BDR. I am not claiming that the behavior noticed is incorrect. I am actually try= ing to understand the below lines of the RFC: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Whether these two bullets are mentioning transition from {DR to (BDR or DR-= Other)}, and {BDR to (DR or DR-other)} Or does it just mean a transition from Non-DR-Other to DR-Other and DR-Othe= r to Non-DR-Other. Where Non-DR-Other means (DR and BDR). Also, given that some DR-Others may detect Neighbor Down later than BDR, is= adjacency flap with BDR expected(though there was no problem in link to BD= R). Thanks and Regards, Bharath R. From: Tanmoy Kundu [mailto:tanmoycs@gmail.com] Sent: Tuesday, June 18, 2013 7:30 PM To: Bharath R Cc: OSPF@ietf.org; Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-St= ate with BDR when DR fails, when DR down detection is delayed at DR-Other. Hi Bharath, Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", h= ow did R2 sensed that R1 is down ? a. first possible option is dead timer expiry in R2. In that case R3 sh= ould also get the expiry soon and till that time the network won't converge= . isn't that expected? b. Another option is having BFD session between R1 and R2, hence it com= es to know. Why don't we run BFD between all the routers in the network ? A= s we know in OSPF the DR and BDR is not guaranteed. This typical scenario is due to the DR-other is with priority zero. But whe= n received hello packet from DR, both BDR and DR-Other should reset the dea= d timer. Even if we consider the link transmission delay and ASIC processin= g, the dead timer expiry difference between R2 and R3 should not be more th= an milisecond, isn't it ? * Is it right to trigger the NeighborChange event at R3? - I feel = yes, other than few typical scenarios the network will at least not be used= , until its converged. If Nbr-chg event is not sent then all DR other feels= that DR is still active and the same will be used for forwarding the traff= ic. If someone in the network sensed that DR/BDR is down, why don't tell ot= hers immediately? * Is this transition from FULL to 2-WAY is expected? - As per RFC,= DR others should not be FULL with other routers than DR and BDR, hence YES= . It is expected. * Can DR-Others flap adjacency with BDR if DR down detection happe= ns later than reception of new Hello from the new DR? - * Intuitively, it may seem desirable to continue to be adjacent to = a neighbor as long as it is still DR or BDR. Is this a fair call? - As ment= ioned above, its not fair to use a disturbed or unsettled network for forwa= rding. Due to backlink check failure the LAN wont be used for forwarding du= ring SPF. Hence as per me its proper behavior. Thanks, Tanmoy On Tue, Jun 18, 2013 at 5:26 PM, Bharath R > wrote: Hi, Please consider the scenario: R1(DR) R2(BDR) | I1 I2 | | | |______________________ | | | I3 | R3(DR-Other) Here: R1 is the DR. R2 is the BDR R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. Following are the is the set of operations and a sequence of events: 1. Interface I1 is disabled. So, DR connectivity is lost to the rest = of the network. 2. R2(The current BDR) detects the DR-down. a. Declares itself the DR. b. Declares BDR as NULL. c. Sends out a Hello with DR as I2 interface address, and BDR as 0.0.= 0.0 3. R3(DR-Other) receives Hello from R2. As per, section 9.2 of RFC 2328: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Triggers a NeighborChange event, which in-turn results in a DR election at = R3. Please note that at this time R3 has not yet detected R1 down. Now result of DR-election at R3: DR: R1 BDR: 0.0.0.0 Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with R2(th= e new DR). Of course, on detection of DR down at R3, R3 will elect R2 as DR and then a= gain transition to ExStart, to Exchange to Full with R2. Can you please let me know: * Is it right to trigger the NeighborChange event at R3 ? * Is this transition from FULL to 2-WAY is expected? * Can DR-Others flap adjacency with BDR if DR down detection happe= ns later than reception of new Hello from the new DR? * Intuitively, it may seem desirable to continue to be adjacent to = a neighbor as long as it is still DR or BDR. Is this a fair call? Please correct me if I have missed out something. Thanks and Regards, Bharath R. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81239BN1PRD0512MB620_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tanmoy,

Thank you for your quick = response.

 <= /p>

Let me give a few clarifi= cations:

 <= /p>

Under the below mentioned= scenario, we would definitely expect a network convergence delay.

But, here, the question i= s regarding the adjacency flap between DR-Other and BDR on DR interface dow= n.

If adjacency is anyway go= ing to flap between DR –Other and BDR under some

scenarios(It is definitel= y possible that in a network some routers detect events faster than the oth= ers),

then is there a significa= nt advantage that we derive from having a BDR?

 <= /p>

Regarding NeighborChange = Event:

Sorry If I was not clear,=

I totally agree that Neig= hborChange Event should be triggered after DR fail is detected.<= /span>

But, the question really = is should the neighbor Change event be triggered when R2(new DR ) sent a ne= w Hello.

Please note that Neighbor= Change event I am referring to  is in response to the Hello as receive= d from the Neighbor and not a result of our DR calculation.

So, If a Neighbor was pre= viously declaring itself a BDR and is now declaring itself a DR(to both of = which we are expected to be adjacent), should the NeighborChange event still be triggered?

 <= /p>

And I don’t think h= aving DR-priority non-zero in DR-Others would have made any difference to t= he above scenario.

R2 instead of declaring B= DR NULL would have declared some other router as BDR(considering a more gen= eric LAN case), and DR other

would have still flapped = the adjacency with the new DR(R2) since R2 was BDR before and is no longer = BDR.

 <= /p>

I am not claiming that th= e behavior noticed is incorrect. I am actually trying to understand the bel= ow lines of the RFC:

 <= /p>

         &nbs= p;  o   One of the bidirectional neighbors is newly declarin= g

         &nbs= p;      itself as either Designated Router or Back= up Designated

         &nbs= p;      Router.  This is detected through exa= mination of that

         &nbs= p;      neighbor's Hello Packets.

 

         &nbs= p;  o   One of the bidirectional neighbors is no longer

         &nbs= p;      declaring itself as Designated Router, or = is no longer

         &nbs= p;      declaring itself as Backup Designated Rout= er.  This is

         &nbs= p;      again detected through examination of that= neighbor's

         &nbs= p;      Hello Packets.

 

Whether these two bullets are mentioning transition from {= DR to (BDR or DR-Other)}, and {BDR to (DR or DR-other)}

Or does it just mean a transition from Non-DR-Other to DR-= Other and DR-Other to Non-DR-Other.

Where Non-DR-Other means (DR and BDR).

 

Also, given that some DR-Others may detect Neighbor Down l= ater than BDR, is adjacency flap with BDR expected(though there was no prob= lem in link to BDR).

 <= /p>

 <= /p>

Thanks and Regards,
Bharath R.

 <= /p>

 <= /p>

From: Tanmoy K= undu [mailto:tanmoycs@gmail.com]
Sent: Tuesday, June 18, 2013 7:30 PM
To: Bharath R
Cc: OSPF@ietf.org; Dileep Singh
Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neig= hbor-State with BDR when DR fails, when DR down detection is delayed at DR-= Other.

 

Hi Bharath, 

Few queries. As you mentioned "R2(= The current BDR) detects the DR-down.", how did R2 sensed that R1 is d= own ?

    a. first possible option = is dead timer expiry in R2. In that case R3 should also get the e= xpiry soon and till that time the network won't converge. isn't that e= xpected? 

    b. Another option is havi= ng BFD session between R1 and R2, hence it comes to know. Why don't we run = BFD between all the routers in the network ? As we know in OSPF the DR and BDR is not guaranteed. 

 

This typical scenario is due to the DR-= other is with priority zero. But when received hello packet from DR, both B= DR and DR-Other should reset the dead timer. Even if we consider the link transmission delay and ASIC processing, the dead timer e= xpiry difference between R2 and R3 should not be more than milisecond, isn'= t it ? 

 

 

·         Is  it right to trigger th= e NeighborChange event at R3? - I feel yes, other than few typical scenario= s the network will at least not be used, until its converged. If Nbr-chg event is not sent then all DR other feels that DR is still acti= ve and the same will be used for forwarding the traffic. If someone in the = network sensed that DR/BDR is down, why don't tell others immediately? = ;

·         Is this transition from FULL to= 2-WAY  is expected? - As per RFC, DR others should not be FULL with o= ther routers than DR and BDR, hence YES. It is expected. 

·         Can DR-Others flap adjacency wi= th BDR if DR down detection  happens later than reception of new Hello= from  the new DR? - 

·         Intuitively, it may seem desira= ble to continue to be adjacent to a neighbor as long as it is still DR or B= DR. Is this a fair call? - As mentioned above, its not fair to use a disturbed or unsettled network for forwarding. Due to backli= nk check failure the LAN wont be used for forwarding during SPF. Hence as p= er me its proper behavior. 

 

 

Thanks,

Tanmoy

 

 

On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juniper.net> wrote:

Hi,

Please consider the scenario:

 

R1(DR)     &nb= sp;            =             &nb= sp;            = R2(BDR)           &= nbsp;    

|  I1     = ;            &n= bsp;            = ;            &n= bsp;    I2   |

|      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

|______________________ |

      &nb= sp;            =              |<= o:p>

      &nb= sp;            =              |&= nbsp; I3           &= nbsp;    

      &nb= sp;            =              |<= o:p>

      &nb= sp;            =    R3(DR-Other)

 

Here:

R1 is the DR.

R2 is the BDR

R3 is DR-Other, with DR-priority 0 and = hence ineligible to become DR/BDR.

 

 

Following are the is the set of operati= ons and a sequence of events:

 

1.    &nb= sp;  Interface I1 is disabled. So, D= R connectivity is lost to the rest of the network.

2.    &nb= sp;  R2(The current BDR) detects the= DR-down.

a.    &nb= sp;  Declares itself the DR.

b.    &nb= sp; Declares BDR as NULL.

c.    &nb= sp;  Sends out a Hello with DR as I2= interface address, and BDR as 0.0.0.0

3.    &nb= sp;  R3(DR-Other) receives Hello fro= m R2.

As per, section 9.2 of RFC 2328:

         &nbs= p;  o   One of the bidirectional neighbors is newly declarin= g

         &nbs= p;      itself as either Designated Router or Back= up Designated

         &nbs= p;      Router.  This is detected through exa= mination of that

         &nbs= p;      neighbor's Hello Packets.

 

         &nbs= p;  o   One of the bidirectional neighbors is no longer

         &nbs= p;      declaring itself as Designated Router, or = is no longer

         &nbs= p;      declaring itself as Backup Designated Rout= er.  This is

         &nbs= p;      again detected through examination of that= neighbor's

         &nbs= p;      Hello Packets.

 

Triggers a NeighborChange event, whi= ch in-turn results in a DR election at R3.

Please note that at this time R3 has= not yet detected R1 down.

Now result of DR-election at R3:

DR: R1

BDR: 0.0.0.0

Since R2 is no longer the BDR, R3 trans= itions from FULL to 2-WAY with R2(the new DR).

Of course, on detection of DR down at R= 3, R3 will elect R2 as DR and then again transition to ExStart, to Exchange= to Full with R2.

 

Can you please let me know:<= /span>

·         Is  it right to trigger th= e NeighborChange event at R3 ?

·         Is this transition from FULL to= 2-WAY  is expected?

·         Can DR-Others flap adjacency wi= th BDR if DR down detection  happens later than reception of new Hello= from  the new DR?

·         Intuitively, it may seem desira= ble to continue to be adjacent to a neighbor as long as it is still DR or B= DR. Is this a fair call?

 

Please correct me if I have missed out = something.

 

 

Thanks and Regards,
Bharath R.

 

 

 

 

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

 

--_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81239BN1PRD0512MB620_-- From stbryant@cisco.com Fri Jun 21 07:39:14 2013 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 03D2521F9BDB; Fri, 21 Jun 2013 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.215, 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 faByYFTegINx; Fri, 21 Jun 2013 07:39:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8C11E8193; Fri, 21 Jun 2013 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8857; q=dns/txt; s=iport; t=1371825548; x=1373035148; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=SZPcSEOoxK3ukKiU5hTJ1TDWrdeF6yPnSvZladOuWK4=; b=ZaPNa+t/BTz+JKpqtEOMviC0zBmDJ6M81l9xuTn5/uQrsZIVLlAClnsW Ovls2DwBkrjSKFtWu7gS4H9F1dTReCNgUJUYhtzp2syr9mG/9fla9XWR+ tYm+y1pSqJ7jwGmhP+vNqtXrAxVzeoO7w/Db6GXAVbNMTR/LZKLEidRh/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAK1kxFGQ/khN/2dsb2JhbABbgwkxiSm2VYECFnSCIwEBAQQBAQFrCgEMBBwDAQIKFg8JAwIBAgEVHwcCCAYBDAEFAgEBF4dzDLxCjX6BOhEHBoNbA5dDgSmQG4MQ X-IronPort-AV: E=Sophos;i="4.87,913,1363132800"; d="scan'208,217";a="14893308" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 21 Jun 2013 14:39:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5LEd4u6025782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 14:39:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r5LEd3hm025510; Fri, 21 Jun 2013 15:39:03 +0100 (BST) Message-ID: <51C46587.3020907@cisco.com> Date: Fri, 21 Jun 2013 15:39:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: isis-wg , "ospf@ietf.org" , "mpls@ietf.org" , "rtgwg@ietf.org" , 6man@ietf.org References: <51C352CA.6000307@cisco.com> In-Reply-To: <51C352CA.6000307@cisco.com> X-Forwarded-Message-Id: <51C352CA.6000307@cisco.com> Content-Type: multipart/alternative; boundary="------------080101000407060509050103" Cc: ops-area@ietf.org Subject: [OSPF] Fwd: Status BOF in Berlin X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:39:14 -0000 This is a multi-part message in MIME format. --------------080101000407060509050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the working groups on the "To" list. I apologies to those that have already seen this through circulation to routing-discussion, but I know that not everyone is subscribed there. The list for discussion of this topic is status@ietf.org - Stewart -------- Original Message -------- Subject: Status BOF in Berlin Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com To: routing-discussion@ietf.org CC: status@ietf.org STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart --------------080101000407060509050103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the
working groups on the "To" list.

I apologies to those that have already seen this through
circulation to routing-discussion, but I know that not
everyone is subscribed there.

The list for discussion of this topic is status@ietf.org

- Stewart

-------- Original Message --------
Subject: Status BOF in Berlin
Date: Thu, 20 Jun 2013 20:06:50 +0100
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
To: routing-discussion@ietf.org
CC: status@ietf.org


STATUS

  • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
  • Status: Approved
  • Description

The IETF has two packet-based forwarding technologies: IP and MPLS.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

Further details can be found  at http://trac.tools.ietf.org/bof/trac/wiki

- Stewart



--------------080101000407060509050103-- From acee.lindem@ericsson.com Sun Jun 23 11:04:53 2013 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 E3B3421F9E05 for ; Sun, 23 Jun 2013 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HiZ3N6RoAUW9 for ; Sun, 23 Jun 2013 11:04:48 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2D21F9DE3 for ; Sun, 23 Jun 2013 11:04:48 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-b9-51c738bd517d Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 77.D2.17537.DB837C15; Sun, 23 Jun 2013 20:04:46 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 14:04:41 -0400 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-acee-ospf-rfc6506bis-03.txt Thread-Index: AQHOcCYH0fiJwuZzO0anN8vWeWBx7Q== Date: Sun, 23 Jun 2013 18:04:40 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47186A35@eusaamb101.ericsson.se> References: <20130623152608.25331.66227.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47186A35eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyuXSPt+4+i+OBBjumcVu03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIf/frMVzLGs2NG2mamB8ZxRFyMnh4SAicS1/T+YIWwxiQv3 1rN1MXJxCAkcZZS413CCCcJZziix+eELsCo2AR2J54/+gdkiArISS5fsZwWxhQV8JD6/bWWE iPtINH3sY+li5ACy9STuL0oFCbMIqEr8eHeOHcTmFfCWWL9gOtgYIQFHic3/F7OB2IxAR3w/ tYYJxGYWEJe49WQ+E8RxAhJL9pyHOlRU4uXjf6wQtrLEkif7WSDq8yXaX61mg5gvKHFy5hOW CYzCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPIbqtZZ4cKuJHVnNAkaOVYwcpcWp ZbnpRgabGIGRckyCTXcH456XlocYpTlYlMR5X57aFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBcdPpzzsmbHy2a4/o80mJTeeErf71fRPKSRI5t3bNIx1xk7CUbRbmr14ucQ73NPji6b// 7qnt++XWx80qjs74tWfOirfcT7o1Kru6u9TObLi8zOfi9bXS5yxN+Q+v5t1jZHCAV8wteMKW bJtPTopHGK68kv1y+pJc6WqeTu5ex1mnJqyWrZ0+fZ4SS3FGoqEWc1FxIgA8xKWdYgIAAA== Subject: [OSPF] Fwd: New Version Notification for draft-acee-ospf-rfc6506bis-03.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: Sun, 23 Jun 2013 18:04:54 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47186A35eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This version includes Marek Karasek's description of transition mode router= operation. Speaking as a WG member, I think we have enough support for WG = adoption. Thanks, Acee Begin forwarded message: From: > Date: June 23, 2013 11:26:08 AM EDT To: Manav Bhatia >, Vishwas Manral >, Acee Lindem > Subject: New Version Notification for draft-acee-ospf-rfc6506bis-03.txt A new version of I-D, draft-acee-ospf-rfc6506bis-03.txt has been successfully submitted by Manav Bhatia and posted to the IETF repository. Filename: draft-acee-ospf-rfc6506bis Revision: 03 Title: Supporting Authentication Trailer for OSPFv3 Creation date: 2013-06-23 Group: Individual Submission Number of pages: 26 URL: http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc650= 6bis-03.txt Status: http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis Htmlized: http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506= bis-03 Abstract: Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. This document obsoletes RFC 6506. The IETF Secretariat --_000_94A203EA12AECE4BA92D42DBFFE0AE47186A35eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable This version includes Marek Karasek's description of transition mode router= operation. Speaking as a WG member, I think we have enough support for WG = adoption. 
Thanks,
Acee

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: June = 23, 2013 11:26:08 AM EDT
To: Manav= Bhatia <manav.bhatia= @alcatel-lucent.com>, Vishwas Manral <vishwas.manral@hp.com>, Acee Lindem <acee.lindem@ericsso= n.com>
Subject: Ne= w Version Notification for draft-acee-ospf-rfc6506bis-03.txt


A new version of I-D, draft-acee-ospf-rfc6506bis-03.txt
has been successfully submitted by Manav Bhatia and posted to the
IETF repository.

Filename: d= raft-acee-ospf-rfc6506bis
Revision: 0= 3
Title: Supporting Auth= entication Trailer for OSPFv3
Creation date: 2013-06-23
Group: Individual Subm= ission
Number of pages: 26
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-03.= txt
Status:          http://datatracke= r.ietf.org/doc/draft-acee-ospf-rfc6506bis
Htmlized:        http://tools.ietf.org/html/dr= aft-acee-ospf-rfc6506bis-03
Diff:            h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc6506bis-03

Abstract:
  Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechan= ism
  for authenticating protocol packets.  This behavior is dif= ferent from
  authentication mechanisms present in other routing protocols (O= SPFv2,
  Intermediate System to Intermediate System (IS-IS), RIP, and Ro= uting
  Information Protocol Next Generation (RIPng)).  In some en= vironments,
  it has been found that IPsec is difficult to configure and main= tain
  and thus cannot be used.  This document defines an alterna= tive
  mechanism to authenticate OSPFv3 protocol packets so that OSPFv= 3 does
  not only depend upon IPsec for authentication.  This docum= ent
  obsoletes RFC 6506.




The IETF Secretariat


--_000_94A203EA12AECE4BA92D42DBFFE0AE47186A35eusaamb101ericsso_-- From acee.lindem@ericsson.com Wed Jun 26 19:13:09 2013 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 42DA011E8200 for ; Wed, 26 Jun 2013 19:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 1lyspJBmmvvN for ; Wed, 26 Jun 2013 19:13:03 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B319211E818F for ; Wed, 26 Jun 2013 19:13:03 -0700 (PDT) X-AuditID: c6180641-b7f986d000000414-f4-51cb9fae516d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 37.72.01044.EAF9BC15; Thu, 27 Jun 2013 04:13:03 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 22:13:02 -0400 From: Acee Lindem To: "Madhukar Anand (anandmkr)" , "ospf@ietf.org" Thread-Topic: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt Thread-Index: AQHOaxB6veIaFt2heUyHZvceKkKAA5k5KtqAgA+ExAA= Date: Thu, 27 Jun 2013 02:13:01 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718BE7B@eusaamb101.ericsson.se> In-Reply-To: <60816F26681B6440A1552440352BAE941DD5E294@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <42DBAC656D7AE141AB980DCEFA07C4DF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPlO76+acDDd6cZbXYvv0ws8X0psOs Fi337rE7MHtM+b2R1WPJkp9MHo+evWEOYI7isklJzcksSy3St0vgylhyZA9zwRqlive//zM1 MDbIdDFyckgImEi03O1lhrDFJC7cW8/WxcjFISRwlFGir3kFM4SznFFiRtt3NpAqNgEdieeP /oF1iAiES/RsvsUOYjMLaEi8/rABzBYWiJHoe3kIqiZW4s2zFywQtpXErU83weawCKhKHJs2 lxHE5hXwlrjxaTOYzSngK7H/32awGkagi76fWsMEMV9c4taT+UwQlwpILNlzHupqUYmXj/+x gtiiAnoSbcfOsEPElSWWPNnPAtGrI7Fg9yc2CNtaYtnvZ4wQtrbEsoWvmSFuEJQ4OfMJywRG 8VlI1s1C0j4LSfssJO2zkLQvYGRdxchRWpxalptuZLiJERhrxyTYHHcwLvhkeYhRmoNFSZz3 /aldgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNSVcX4d2VV3IsZ+z2XYT0z+Lvi13j1dO 3/veIXbu/zszjqVpKWxku2lmF73c4GpIzXN7YzON2R5KKk9PLdiWs8T256Q1rQZXv39ZrW+x z9W4wLWh+MEdg61596xfTe7ymOr2xWabaMOsD568Uwvakq7t8zP1YHgwtSX+THPOe7kzW5jF j06XVGIpzkg01GIuKk4EALY+VGqDAgAA Cc: Madhukar Anand Subject: Re: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.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, 27 Jun 2013 02:13:09 -0000 Hi Madhakar,=20 For auto-configured routers, we have previously added that we simply default to the asymmetric behavior without additional requiring additional LLS encoding. Here is an excerpt from draft-ietf-ospf-ospfv3-autoconfig-02.txt: 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility Auto-configured OSPFv3 routers will not require an identical HelloInterval and RouterDeadInterval to form adjacencies. Rather, the received HelloInterval will be ignored and the received RouterDeadInterval will be used to determine OSPFv3 liveliness with the sending router. In other words, the Inactivity Timer for each neighbor will reflect that neighbor's advertised RouterDeadInterval and MAY be different from other OSPFv3 routers on the link without impacting adjacency formation. A similar mechanism requiring additional signaling is proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO].=20 Hence, I believe we disagree on this point. It would be good to get WG discussion on this point. Thanks, Acee=20 On 6/16/13 9:14 PM, "Madhukar Anand (anandmkr)" wrote: > >Thanks for all the feedback. We have made 3 modifications modifications to >the previous draft: > > >(1) In the introduction, we have added OSPFv3 Autoconfig as another >use-case: > >Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for >flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of >[OSPFV3-AUTOCONFIG]). These requirements can be easily met by implementing >the proposal here. > > >(2) In 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. > > Routers that recognize this new extended options will set the > value of the neighbor dead interval to the value specified in the LLS > block TLV, but only if BOTH the HELLO and dead interval are set to > zero in the OSPF HELLO packet. > > > >(3) We have also summarized the discussion section and the relation of >this proposal w.r.t. BFD. > >It is possible to use Bidirectional Forwarding Detection (BFD) [RFC 5880] >to alleviate some of the concerns in the use-cases identified above. >Relying entirely on BFD without OSPF HELLOs is not a >possibility given that OSPF HELLOs are still used for discovery of >neighbors. The BFD approach has its own shortcomings such as limited >cross-vendor and cross-platform support and also performance implications, >especially with increasing scale requirements. In any case, BFD can be >made to work in conjunction with the proposal in this document to achieve >the best possible network performance. It is intended that the proposal >for asymmetric hold timer would work independent of BFD deployment >considerations, and could also help in new applications where it may be >desirable to support asymmetric and possibly dynamic dead interval values >(e.g., OSPFv3 Auto-Configuration, [OSPFV3-AUTOCONFIG]). > > > >Thanks, >Madhukar > > > >On 6/16/13 9:09 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-madhukar-ospf-agr-asymmetric-01.txt >>has been successfully submitted by Madhukar Anand and posted to the >>IETF repository. >> >>Filename: draft-madhukar-ospf-agr-asymmetric >>Revision: 01 >>Title: Asymmetric OSPF Hold Timer >>Creation date: 2013-06-16 >>Group: Individual Submission >>Number of pages: 10 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-madhukar-ospf-agr-asymmetric-01 >>. >>txt >>Status: =20 >>http://datatracker.ietf.org/doc/draft-madhukar-ospf-agr-asymmetric >>Htmlized: =20 >>http://tools.ietf.org/html/draft-madhukar-ospf-agr-asymmetric-01 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-madhukar-ospf-agr-asymmetric-01 >> >>Abstract: >> Current OSPF standard requires that the HELLO/Dead interval be >> symmetric on either side of the link in order to maintain adjacency. >> There are many scenarios in which this may not be desirable. This >> memo describes a technique to allow OSPF adjacency to be maintained >> with asymmetric values of the OSPF Dead interval. >> >> >> =20 >> =20 >> >> >>The IETF Secretariat >> > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Thu Jun 27 07:44:55 2013 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 1576A21F9C3A for ; Thu, 27 Jun 2013 07:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IZSvoS2kLmVh for ; Thu, 27 Jun 2013 07:44:49 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DED3321F9CE1 for ; Thu, 27 Jun 2013 07:44:47 -0700 (PDT) X-AuditID: c6180641-b7f5b6d000002d97-21-51cc4c4d0c51 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.BB.11671.D4C4CC15; Thu, 27 Jun 2013 16:29:34 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 10:29:33 -0400 From: Acee Lindem To: Tanmoy Kundu Thread-Topic: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. Thread-Index: Ac5sGnznNwBh+oLtRnGrauEoRknkhf//8RyAgA6LkAA= Date: Thu, 27 Jun 2013 14:29:33 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718CDEF@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4718CDEFeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn66fz5lAg1N3GS12rdrHZtFy7x67 xa7r+xgtfj1ewuTA4rFz1l12jyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CVseV6I2PB8VbG ita1fawNjEcKuhg5OCQETCQe7pfsYuQEMsUkLtxbz9bFyMUhJHCUUWLH5DNQznJGiZ3z7zKB VLEJ6Eg8f/SPGcQWEVCVaLy8FyzOLJArsa7vLRNIg7DATEaJk3P+soI4IgKzGCUe/7rNDtFh JfH490qwDhag7r4lbxlBbF4Bb4mbs6azgNiMQHd8P7UGaqq4xK0n85kg7hOQWLLnPDOELSrx 8vE/VhBbVEBPou3YGXaIuLLEkif7WSB68yU2Xb3GCjFfUOLkzCcsExhFZiEZOwtJ2SwkZRBx HYkFuz+xQdjaEssWvmaGsc8ceAzVay3xu6OJCVnNAkaOVYwcpcWpZbnpRoabGIGRd0yCzXEH 44JPlocYpTlYlMR5N+idCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKHvp0CehNwcTU750 88o/+d+zYUHZgd+7Qvb2FCTuOMKw3HjN/fDkqK07l3EU7tX+0vbvbJDM2SPi90NWeLw+q3Xh j4f70jkmZWltzGtXt1uGbvvHbb2rfp1ycotXqNWfXn0XSWaXi/KB3tqZl/IP9IXyX9i3W2NB 2ZHQvHoLnTvZvUzpYf9jlViKMxINtZiLihMBFC28DYoCAAA= Cc: "OSPF@ietf.org" , Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. 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, 27 Jun 2013 14:44:55 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4718CDEFeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tanmoy that this is proper behavior. Thanks, Acee On Jun 18, 2013, at 10:00 AM, Tanmoy Kundu wrote: Hi Bharath, Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", h= ow did R2 sensed that R1 is down ? a. first possible option is dead timer expiry in R2. In that case R3 sh= ould also get the expiry soon and till that time the network won't converge= . isn't that expected? b. Another option is having BFD session between R1 and R2, hence it com= es to know. Why don't we run BFD between all the routers in the network ? A= s we know in OSPF the DR and BDR is not guaranteed. This typical scenario is due to the DR-other is with priority zero. But whe= n received hello packet from DR, both BDR and DR-Other should reset the dea= d timer. Even if we consider the link transmission delay and ASIC processin= g, the dead timer expiry difference between R2 and R3 should not be more th= an milisecond, isn't it ? * Is it right to trigger the NeighborChange event at R3? - I feel yes,= other than few typical scenarios the network will at least not be used, un= til its converged. If Nbr-chg event is not sent then all DR other feels tha= t DR is still active and the same will be used for forwarding the traffic. = If someone in the network sensed that DR/BDR is down, why don't tell others= immediately? * Is this transition from FULL to 2-WAY is expected? - As per RFC, DR = others should not be FULL with other routers than DR and BDR, hence YES. It= is expected. * Can DR-Others flap adjacency with BDR if DR down detection happens l= ater than reception of new Hello from the new DR? - * Intuitively, it may seem desirable to continue to be adjacent to a ne= ighbor as long as it is still DR or BDR. Is this a fair call? - As mentione= d above, its not fair to use a disturbed or unsettled network for forwardin= g. Due to backlink check failure the LAN wont be used for forwarding during= SPF. Hence as per me its proper behavior. Thanks, Tanmoy On Tue, Jun 18, 2013 at 5:26 PM, Bharath R > wrote: Hi, Please consider the scenario: R1(DR) R2(BDR) | I1 I2 | | | |______________________ | | | I3 | R3(DR-Other) Here: R1 is the DR. R2 is the BDR R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. Following are the is the set of operations and a sequence of events: 1. Interface I1 is disabled. So, DR connectivity is lost to the rest of = the network. 2. R2(The current BDR) detects the DR-down. 1. Declares itself the DR. 2. Declares BDR as NULL. 3. Sends out a Hello with DR as I2 interface address, and BDR as 0.0.0.0 1. R3(DR-Other) receives Hello from R2. As per, section 9.2 of RFC 2328: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Triggers a NeighborChange event, which in-turn results in a DR election at = R3. Please note that at this time R3 has not yet detected R1 down. Now result of DR-election at R3: DR: R1 BDR: 0.0.0.0 Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with R2(th= e new DR). Of course, on detection of DR down at R3, R3 will elect R2 as DR and then a= gain transition to ExStart, to Exchange to Full with R2. Can you please let me know: * Is it right to trigger the NeighborChange event at R3 ? * Is this transition from FULL to 2-WAY is expected? * Can DR-Others flap adjacency with BDR if DR down detection happens l= ater than reception of new Hello from the new DR? * Intuitively, it may seem desirable to continue to be adjacent to a ne= ighbor as long as it is still DR or BDR. Is this a fair call? Please correct me if I have missed out something. Thanks and Regards, Bharath R. _______________________________________________ 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 --_000_94A203EA12AECE4BA92D42DBFFE0AE4718CDEFeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I agree with Tanmoy that this is proper behavior. 
Thanks,
Acee
On Jun 18, 2013, at 10:00 AM, Tanmoy Kundu wrote:

Hi Bharath, 
Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", how did R2= sensed that R1 is down ?
    a.= first possible option is dead timer expiry in R2. In that case R3 sho= uld also get the expiry soon and till that time the network won't= converge. isn't that expected? 
    b.= Another option is having BFD session between R1 and R2, hence it comes to = know. Why don't we run BFD between all the routers in the network ? As we k= now in OSPF the DR and BDR is not guaranteed. 

This typical sce= nario is due to the DR-other is with priority zero. But when received hello= packet from DR, both BDR and DR-Other should reset the dead timer. Even if= we consider the link transmission delay and ASIC processing, the dead timer expiry difference between R2 and R3 sh= ould not be more than milisecond, isn't it ? 


  • Is  it right to trigger the NeighborCha= nge event at R3? - I feel yes, other than few typical scenarios the network= will at least not be used, until its converged. If Nbr-chg event is not se= nt then all DR other feels that DR is still active and the same will be used for forwarding the traffic. If someone in= the network sensed that DR/BDR is down, why don't tell others immediately?=  
  • Is this transition from FULL to 2-WAY&n= bsp; is expected? - As per RFC, DR others should not be FULL with other rou= ters than DR and BDR, hence YES. It is expected. 
  • Can DR-Others flap adjacency with BDR if DR down detection&n= bsp; happens later than reception of new Hello from  the new DR? -&nbs= p;
  • Intuitively, it may seem desirable to= continue to be adjacent to a neighbor as long as it is still DR or BDR. Is= this a fair call? - As mentioned above, its not fair to use a disturbed or= unsettled network for forwarding. Due to backlink check failure the LAN wont be used for forwarding during SPF. Hen= ce as per me its proper behavior. 


Thanks,
Tanmoy



On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juni= per.net> wrote:
Hi,
Please consider the scenario:
 
R1(DR)          &nbs= p;            &= nbsp;           &nbs= p;        R2(BDR)    = ;             <= /div>
|  I1          =             &nb= sp;            =             I2 =   |
|           &nb= sp;            =             &nb= sp;            =            |
|______________________ |
           &nbs= p;            &= nbsp;       |
           &nbs= p;            &= nbsp;       |  I3    = ;             <= /div>
           &nbs= p;            &= nbsp;       |
           &nbs= p;          R3(DR-Other)
 
Here:
R1 is the DR.
R2 is the BDR
R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/B= DR.
 
 
Following are the is the set of operations and a sequence of events:
 
  1. Interface I1 is disabled. So, DR connectivity is lost to the rest of th= e network.
  2. R2(The current BDR) detects the DR-down.
  1. Declares itself the DR.
  2. Declares BDR as NULL.
  3. Sends out= a Hello with DR as I2 interface address, and BDR as 0.0.0.0
  1. R3(DR-Other) receives Hello from R2.
As per, section 9.2 of RFC 2328:
 &nbs= p;          o   One = of the bidirectional neighbors is newly declaring
 &nbs= p;            &= nbsp; itself as either Designated Router or Backup Designated=
 &nbs= p;            &= nbsp; Router.  This is detected through examination of that
 &nbs= p;            &= nbsp; neighbor's Hello Packets.
 
 &nbs= p;          o   One = of the bidirectional neighbors is no longer
 &nbs= p;            &= nbsp; declaring itself as Designated Router, or is no longer<= /div>
 &nbs= p;            &= nbsp; declaring itself as Backup Designated Router.  This is
 &nbs= p;            &= nbsp; again detected through examination of that neighbor's
 &nbs= p;            &= nbsp; Hello Packets.
 
Triggers a NeighborChange e<= b>vent, which in-turn results in a DR election at R3.
Please note that at this time R3 has no= t yet detected R1 down.
Now result of DR-election at R3:
DR: R1
BDR: 0.0.0.0
Since R2 is no longer the BDR, R3 transiti= ons from FULL to 2-WAY with R2(the new DR).
Of course, on detection of DR down at R3, = R3 will elect R2 as DR and then again transition to ExStart, to Exchange to= Full with R2.
 
Can you please let me know:
  • Is  it right to trigger the NeighborChange event at R3 ?
  • I= s this transition from FULL to 2-WAY  is expected?
  • Can DR-Othe= rs flap adjacency with BDR if DR down detection  happens later than re= ception of new Hello from  the new DR?
  • Intuitively, it may seem desirable to continue to be adjacent to a= neighbor as long as it is still DR or BDR. Is this a fair call?
 
Please correct me if I have missed out something.
 
 
Thanks and Regards,
Bharath R.
 
 
 
 
 

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org= /mailman/listinfo/ospf

--_000_94A203EA12AECE4BA92D42DBFFE0AE4718CDEFeusaamb101ericsso_-- From acee.lindem@ericsson.com Thu Jun 27 13:18:12 2013 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 F28DC11E80D1 for ; Thu, 27 Jun 2013 13:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4HCcroyF+NnI for ; Thu, 27 Jun 2013 13:18:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDD21F9EFB for ; Thu, 27 Jun 2013 13:18:02 -0700 (PDT) X-AuditID: c618062d-b7fc76d0000063be-4d-51cc9df9838d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.34.25534.9FD9CC15; Thu, 27 Jun 2013 22:18:01 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 16:18:01 -0400 From: Acee Lindem To: "OSPF@ietf.org" Thread-Topic: OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOc3NrhDx5rAEZaU6K9RwM6LdMag== Date: Thu, 27 Jun 2013 20:18:00 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4718D71Beusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPn+7PuWcCDS7/tbFouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXMOXmUqOKlUceXwFLYGxgcyXYycHBICJhIbN39nhbDFJC7c W8/WxcjFISRwlFHizaQjLCAJIYHljBLff6uC2GwCOhLPH/1jBrFFBJQlzt9qYe9i5OAQFvCQ mHnUDiLsK9G98zw7hK0nMfnQfUYQm0VAVaJ16gwmEJtXwFti7rQlYHsZgfZ+P7UGLM4sIC5x 68l8Joh7BCSW7DnPDGGLSrx8/A+sXhRoZtuxM+wQcWWJJU/2s0D05kss2DAbar6gxMmZT1gm MArPQjJ2FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwGKrXWuJGx252ZDULGDlWMXKUFqeW 5aYbGWxiBMbJMQk23R2Me15aHmKU5mBREuddpXcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VANj5yXvoKgO45v7psp9XFQnMmXSkuab2pfkeWU33rWK+X/U90JfstuUVaJVu7vKvtxM7Z78 TftB2+brx82uX3n+t+3UvfUHfbbM8ImvCHVNSdgcu+XFss9X1za8aZb8cyTpCvOKWzdPndx2 q3ie9nW3torAike+Rv3sbFU8gReEmeM3h2bzSBQuUGIpzkg01GIuKk4EAPsPZFhhAgAA Subject: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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, 27 Jun 2013 20:18:12 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4718D71Beusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think there is much disagreement that we need a direct way to exten= d the base OSPFv3 LSAs and I will be presenting this draft at IETF 87 in Be= rlin. Where there appears to be some amount of disagreement is in the backw= ard compatibility mechanisms. There are basically 3 options (as well as sub= tle variants) 1. The approach in the draft, only allow adjacencies between router= s supporting the extended encodings. Backward compatibility would have to b= e provided with separate instances and topology. 2. Both the current and extended versions of the LSAs are originated= as long as there are routers not supporting the new extended encodings at = the respective flooding scope. This was the approach taken in "Multi-toplog= y routing in OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt. However= , it has the undesirable property of roughly doubling the size of the LSDB. 3. Switch to the extended format only after all the routers at the fl= ooding scope support it. Use OSPF demand circuit-like (RFC 1793) signaling = to determine whether or not all routers in the flooding scope support the n= ew format. The only potential problem with this approach is a dynamics when= a router not supporting the extended format successively leaves and enters= the routing domain. What is the WG preference? I'm still in favor of the approach in the draft = (#1) given the simplicity and stability properties. What we'd lose in slowe= d deployment would be more than made up standardization and availability. A= lso, it would satisfy the homenet requirements we desperately need to satis= fy. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4718D71Beusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <11700719008B92478695020A34E163B3@ericsson.com> Content-Transfer-Encoding: quoted-printable
I don't think there is much disagreement that we need a direct way to = extend the base OSPFv3 LSAs and I will be presenting this draft at IETF 87 = in Berlin. Where there appears to be some amount of disagreement is in the = backward compatibility mechanisms. There are basically 3 options (as well as subtle variants)


        1. The approach in the draft, only allow a= djacencies between routers supporting the extended encodings. Backward comp= atibility would have to be provided with separate instances and topology.&n= bsp;

       2. Both the current and extended versions o= f the LSAs are originated as long as there are routers not supporting the n= ew extended encodings at the respective flooding scope. This was the approa= ch taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)&quo= t;, draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable property= of roughly doubling the size of the LSDB. 

      3. Switch to the extended format only after all t= he routers at the flooding scope support it. Use OSPF demand circuit-like (= RFC 1793) signaling to determine whether or not all routers in the flooding= scope support the new format. The only potential problem with this approach is a dynamics when a router not supporting the = extended format successively leaves and enters the routing domain. 

What is the WG preference? I'm still in favor of the approach in the d= raft (#1) given the simplicity and stability properties. What we'd lose in = slowed deployment would be more than made up standardization and availabili= ty. Also, it would satisfy the homenet requirements we desperately need to satisfy. 

Thanks,
Acee 

--_000_94A203EA12AECE4BA92D42DBFFE0AE4718D71Beusaamb101ericsso_-- From mjbarnes@cisco.com Thu Jun 27 13:28:56 2013 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 D603521F9DFD for ; Thu, 27 Jun 2013 13:28:56 -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 Qr4cpSAW44Yi for ; Thu, 27 Jun 2013 13:28:52 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D928121F9F61 for ; Thu, 27 Jun 2013 13:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2801; q=dns/txt; s=iport; t=1372364915; x=1373574515; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9xi4U6EbHIt/VGZqfRHtEXfvtTYYIxnzqvtCzWekOdU=; b=foN8CAkQk9A/PCStjjkEPM17oTMg+jDoXInugchn70eGK1doATMqqzk6 Ia2VGw/K0CGmGeD2nT7fMdA/oeERKKhpGqQs9qI5ULtYe41urcz+W/WIk 7d4jKWGW66wqFI5zTfJcaNRkeyNnZ+1/nZeQWGSNDlNQkPg/ndMB4WIDR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAOSfzFGrRDoI/2dsb2JhbABbgwkxAb9UgQIWdIIjAQEBAQMBAQE1NgoRCxgJFg8JAwIBAgEVMBMGAgEBiAkNuzkEj1wWg08DiSKOI4YhiySDMRw X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="81954574" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Jun 2013 20:28:30 +0000 Received: from [10.21.121.3] (sjc-vpn6-259.cisco.com [10.21.121.3]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5RKSTrS014458 for ; Thu, 27 Jun 2013 20:28:29 GMT Message-ID: <51CCA06C.5080508@cisco.com> Date: Thu, 27 Jun 2013 13:28:28 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ospf@ietf.org References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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, 27 Jun 2013 20:28:57 -0000 My preference would be for Option 2. This will allow the new LSAs to be used for enhancements that we have not yet envisioned. Regarding the doubling of the LSDB size, I would say that there should be configuration options on whether the new LSAs should be used so that an operator can control this. It would allow an operator to keep the new LSAs from being originated until all of the routers can originate them. On the other hand, another operator might have a need for new LSAs before the area fully supports them and choose to live with the increased LSDB size. IMHO that flexibility is very desirable. I would also say that the U bit should be set. This would allow, for example, the External LSA to be enhanced to carry some information that would only be of interest to another ASBR or an ABR, and it wouldn't matter if other routers understood it. Regards, Michael On 06/27/2013 01:18 PM, Acee Lindem wrote: > I don't think there is much disagreement that we need a direct way to > extend the base OSPFv3 LSAs and I will be presenting this draft at IETF > 87 in Berlin. Where there appears to be some amount of disagreement is > in the backward compatibility mechanisms. There are basically 3 options > (as well as subtle variants) > > > 1. The approach in the draft, only allow adjacencies between > routers supporting the extended encodings. Backward compatibility would > have to be provided with separate instances and topology. > > 2. Both the current and extended versions of the LSAs are > originated as long as there are routers not supporting the new extended > encodings at the respective flooding scope. This was the approach taken > in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", > draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable > property of roughly doubling the size of the LSDB. > > 3. Switch to the extended format only after all the routers at > the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) > signaling to determine whether or not all routers in the flooding scope > support the new format. The only potential problem with this approach is > a dynamics when a router not supporting the extended format successively > leaves and enters the routing domain. > > What is the WG preference? I'm still in favor of the approach in the > draft (#1) given the simplicity and stability properties. What we'd lose > in slowed deployment would be more than made up standardization and > availability. Also, it would satisfy the homenet requirements we > desperately need to satisfy. > > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From ppsenak@cisco.com Thu Jun 27 13:43:49 2013 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 7B9E821F9E15 for ; Thu, 27 Jun 2013 13:43:49 -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 fJxHS7MPzvf6 for ; Thu, 27 Jun 2013 13:43:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1921F9DA3 for ; Thu, 27 Jun 2013 13:43:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5RKhh93005182 for ; Thu, 27 Jun 2013 22:43:44 +0200 (CEST) Received: from ams-ppsenak-8716.cisco.com (ams-ppsenak-8716.cisco.com [10.55.51.199]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5RKhgaF011844; Thu, 27 Jun 2013 22:43:42 +0200 (CEST) Message-ID: <51CCA3FE.5030505@cisco.com> Date: Thu, 27 Jun 2013 22:43:42 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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, 27 Jun 2013 20:43:49 -0000 Hi Acee, my preference is option (2). thanks, Peter On 27.6.2013 22:18, Acee Lindem wrote: > I don't think there is much disagreement that we need a direct way to > extend the base OSPFv3 LSAs and I will be presenting this draft at IETF > 87 in Berlin. Where there appears to be some amount of disagreement is > in the backward compatibility mechanisms. There are basically 3 options > (as well as subtle variants) > > > 1. The approach in the draft, only allow adjacencies between > routers supporting the extended encodings. Backward compatibility would > have to be provided with separate instances and topology. > > 2. Both the current and extended versions of the LSAs are > originated as long as there are routers not supporting the new extended > encodings at the respective flooding scope. This was the approach taken > in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", > draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable > property of roughly doubling the size of the LSDB. > > 3. Switch to the extended format only after all the routers at > the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) > signaling to determine whether or not all routers in the flooding scope > support the new format. The only potential problem with this approach is > a dynamics when a router not supporting the extended format successively > leaves and enters the routing domain. > > What is the WG preference? I'm still in favor of the approach in the > draft (#1) given the simplicity and stability properties. What we'd lose > in slowed deployment would be more than made up standardization and > availability. Also, it would satisfy the homenet requirements we > desperately need to satisfy. > > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Thu Jun 27 13:53:21 2013 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 751EA21F9D27 for ; Thu, 27 Jun 2013 13:53:20 -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=[AWL=0.001, 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 1XPWjUfULIWs for ; Thu, 27 Jun 2013 13:53:13 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0B44221F8481 for ; Thu, 27 Jun 2013 13:53:11 -0700 (PDT) X-AuditID: c6180641-b7f5b6d000002d97-22-51cca637d170 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F1.56.11671.736ACC15; Thu, 27 Jun 2013 22:53:11 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 16:53:09 -0400 From: Acee Lindem To: Peter Psenak Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOc3cK9jIpbh4OU0Cj0JPpZl1KwZlJ18iA Date: Thu, 27 Jun 2013 20:53:08 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se> In-Reply-To: <51CCA3FE.5030505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXSPt675sjOBBlcPqFq03LvHbrFjdzub A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxd/trxoIu4YobdxpZGhhX8ncxcnJICJhI LOv9wgRhi0lcuLeerYuRi0NI4CijxK7Pu5ghnOWMEm8frmAEqWIT0JF4/ugfM4gtIqAiMe96 DwuIzSygLPH30HowW1ggROLYzKfsEDWhEsc/roKqN5I4umM2K4jNIqAq8Xr9XDCbV8Bb4sKs LjYQm1NAU2LF1XawXkagi76fWsMEMV9c4taT+VCXCkgs2XOeGcIWlXj5+B/YHFEBPYm2Y2fY IeLKEkue7Ie6TUdiwe5PbBC2tcTOm+8ZIWxtiWULXzND3CAocXLmE5YJjOKzkKybhaR9FpL2 WUjaZyFpX8DIuoqRo7Q4tSw33chwEyMwro5JsDnuYFzwyfIQozQHi5I47wa9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKWAEXONbfIS2Xc3s9z6mvxjdniI/f43dfMlidiXEg4Cb3//VWC4 tlY3U9Di2et/O75ES81f0L5CkuXN0tXntxxwLhRRb/v5SpxZyuB/3uNG71/V//kUC87+f3WO eUey5b75dxlivDfOPr3ZiPNa7ASOhxXMqTziH55r/p98ru5JtqZY0ZKZ1uePGSixFGckGmox FxUnAgDmZMHkeQIAAA== Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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, 27 Jun 2013 20:53:22 -0000 Peter, Michael,=20 I guess you guys have considered the complexity this adds. For example, you now need rules for LSDB entry selection during the SPF given that the calculation will now have to handle a mix of extended and non-extended LSAs. #2 is actually my least favorite of the three options given the complexity it burdens us with forever. Acee=20 On 6/27/13 1:43 PM, "Peter Psenak" wrote: >Hi Acee, > >my preference is option (2). > >thanks, >Peter > > >On 27.6.2013 22:18, Acee Lindem wrote: >> I don't think there is much disagreement that we need a direct way to >> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF >> 87 in Berlin. Where there appears to be some amount of disagreement is >> in the backward compatibility mechanisms. There are basically 3 options >> (as well as subtle variants) >> >> >> 1. The approach in the draft, only allow adjacencies between >> routers supporting the extended encodings. Backward compatibility would >> have to be provided with separate instances and topology. >> >> 2. Both the current and extended versions of the LSAs are >> originated as long as there are routers not supporting the new extended >> encodings at the respective flooding scope. This was the approach taken >> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >> property of roughly doubling the size of the LSDB. >> >> 3. Switch to the extended format only after all the routers at >> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >> signaling to determine whether or not all routers in the flooding scope >> support the new format. The only potential problem with this approach is >> a dynamics when a router not supporting the extended format successively >> leaves and enters the routing domain. >> >> What is the WG preference? I'm still in favor of the approach in the >> draft (#1) given the simplicity and stability properties. What we'd lose >> in slowed deployment would be more than made up standardization and >> availability. Also, it would satisfy the homenet requirements we >> desperately need to satisfy. >> >> Thanks, >> Acee >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > From ppsenak@cisco.com Thu Jun 27 14:43:09 2013 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 8892221F9EC1 for ; Thu, 27 Jun 2013 14:43:09 -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 W3leHxBUOVRE for ; Thu, 27 Jun 2013 14:43:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 10AE121F9EBD for ; Thu, 27 Jun 2013 14:43:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5RLh2vX010536 for ; Thu, 27 Jun 2013 23:43:02 +0200 (CEST) Received: from ams-ppsenak-8716.cisco.com (ams-ppsenak-8716.cisco.com [10.55.51.199]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5RLguCL005527; Thu, 27 Jun 2013 23:42:56 +0200 (CEST) Message-ID: <51CCB1DF.1030703@cisco.com> Date: Thu, 27 Jun 2013 23:42:55 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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, 27 Jun 2013 21:43:09 -0000 Hi Acee, yes, I have considered the complexity of (2). On the other hand (2) is also the most flexible one from the deployment perspective. It allows you to use new LSAs to advertise some new attributes for a link/prefix, while keeping the old LSA for what you use them today. Later when all routers understand the new format old LSAs can be removed. Option (1) is not a realistic one from the deployment perspective IMHO. thanks, Peter On 27.6.2013 22:53, Acee Lindem wrote: > Peter, Michael, > I guess you guys have considered the complexity this adds. For example, > you now need rules for LSDB entry selection during the SPF given that the > calculation will now have to handle a mix of extended and non-extended > LSAs. #2 is actually my least favorite of the three options given the > complexity it burdens us with forever. > > Acee > > On 6/27/13 1:43 PM, "Peter Psenak" wrote: > >> Hi Acee, >> >> my preference is option (2). >> >> thanks, >> Peter >> >> >> On 27.6.2013 22:18, Acee Lindem wrote: >>> I don't think there is much disagreement that we need a direct way to >>> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF >>> 87 in Berlin. Where there appears to be some amount of disagreement is >>> in the backward compatibility mechanisms. There are basically 3 options >>> (as well as subtle variants) >>> >>> >>> 1. The approach in the draft, only allow adjacencies between >>> routers supporting the extended encodings. Backward compatibility would >>> have to be provided with separate instances and topology. >>> >>> 2. Both the current and extended versions of the LSAs are >>> originated as long as there are routers not supporting the new extended >>> encodings at the respective flooding scope. This was the approach taken >>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>> property of roughly doubling the size of the LSDB. >>> >>> 3. Switch to the extended format only after all the routers at >>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>> signaling to determine whether or not all routers in the flooding scope >>> support the new format. The only potential problem with this approach is >>> a dynamics when a router not supporting the extended format successively >>> leaves and enters the routing domain. >>> >>> What is the WG preference? I'm still in favor of the approach in the >>> draft (#1) given the simplicity and stability properties. What we'd lose >>> in slowed deployment would be more than made up standardization and >>> availability. Also, it would satisfy the homenet requirements we >>> desperately need to satisfy. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> >> > > > From asmirnov@cisco.com Fri Jun 28 01:01:19 2013 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 4E56521F941F for ; Fri, 28 Jun 2013 01:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 gnypcevw4WSm for ; Fri, 28 Jun 2013 01:01:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A182F21F9EE4 for ; Fri, 28 Jun 2013 01:01:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5S811vn016257; Fri, 28 Jun 2013 10:01:01 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5S80MCh023850; Fri, 28 Jun 2013 10:00:37 +0200 (CEST) Message-ID: <51CD4296.1030108@cisco.com> Date: Fri, 28 Jun 2013 10:00:22 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 08:01:19 -0000 Hi Acee, while I appreciate developer's simplicity of option 1 this approach is good only for greenfield deployment. For any existing sizable OSPFv3 network its migration limitation may become an insurmountable obstacle. My preference is combination of options: start migration as option 2 and when migration is completed lock on 1. Benefits are that migration is possible; LSDB is doubled only for period of migration; and once migration is completed there is no need to worry about dynamics of old-style router entering the domain. Downside is relative complexity of implementation but that's the price to pay for simplicity of OSPFv3. BTW, entering and exiting migration may be manual (via configuration), so this mixed approach may be simpler to implement than 'pure' option 3. Said all that, individual products targeting greenfield deployment scenario may skip implementation of migration. Say, homenet may require support of extended LSAs from day 1. That would mean that homenet products will not be deployable in existing old-style-LSA networks - but that probably is not the intent anyway. Anton On 06/27/2013 10:18 PM, Acee Lindem wrote: > I don't think there is much disagreement that we need a direct way to > extend the base OSPFv3 LSAs and I will be presenting this draft at IETF > 87 in Berlin. Where there appears to be some amount of disagreement is > in the backward compatibility mechanisms. There are basically 3 options > (as well as subtle variants) > > > 1. The approach in the draft, only allow adjacencies between > routers supporting the extended encodings. Backward compatibility would > have to be provided with separate instances and topology. > > 2. Both the current and extended versions of the LSAs are > originated as long as there are routers not supporting the new extended > encodings at the respective flooding scope. This was the approach taken > in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", > draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable > property of roughly doubling the size of the LSDB. > > 3. Switch to the extended format only after all the routers at > the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) > signaling to determine whether or not all routers in the flooding scope > support the new format. The only potential problem with this approach is > a dynamics when a router not supporting the extended format successively > leaves and enters the routing domain. > > What is the WG preference? I'm still in favor of the approach in the > draft (#1) given the simplicity and stability properties. What we'd lose > in slowed deployment would be more than made up standardization and > availability. Also, it would satisfy the homenet requirements we > desperately need to satisfy. > > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee@lindem.com Fri Jun 28 02:44:40 2013 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 C009321F9EE4 for ; Fri, 28 Jun 2013 02:44:40 -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 E12z-OGrhvQY for ; Fri, 28 Jun 2013 02:44:30 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B321F9EE0 for ; Fri, 28 Jun 2013 02:44:27 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=f9nK9ZOM c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=ghmeUnvl0TIA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=ho3YfyqrwZAA:10 a=48vgC7mUAAAA:8 a=IPX084dgh9OmR5iSsh0A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:57560] helo=[192.168.1.105]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 4C/F8-05415-9FA5DC15; Fri, 28 Jun 2013 09:44:26 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <51CD4296.1030108@cisco.com> Date: Fri, 28 Jun 2013 05:44:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> To: Anton Smirnov , Peter Psenak X-Mailer: Apple Mail (2.1085) Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 09:44:40 -0000 Hi Anton, Peter,=20 If I were to be convinced that #2 is the way to go, I like making it = explicit configurations and only applicable to service provider and = large enterprise deployments. That way, OSPFv3 implementations = specifically for the homenet environments could omit it.=20 Thanks, Acee On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: > Hi Acee, > while I appreciate developer's simplicity of option 1 this approach = is good only for greenfield deployment. For any existing sizable OSPFv3 = network its migration limitation may become an insurmountable obstacle. > My preference is combination of options: start migration as option 2 = and when migration is completed lock on 1. > Benefits are that migration is possible; LSDB is doubled only for = period of migration; and once migration is completed there is no need to = worry about dynamics of old-style router entering the domain. > Downside is relative complexity of implementation but that's the = price to pay for simplicity of OSPFv3. BTW, entering and exiting = migration may be manual (via configuration), so this mixed approach may = be simpler to implement than 'pure' option 3. > Said all that, individual products targeting greenfield deployment = scenario may skip implementation of migration. Say, homenet may require = support of extended LSAs from day 1. That would mean that homenet = products will not be deployable in existing old-style-LSA networks - but = that probably is not the intent anyway. >=20 > Anton >=20 >=20 > On 06/27/2013 10:18 PM, Acee Lindem wrote: >> I don't think there is much disagreement that we need a direct way to >> extend the base OSPFv3 LSAs and I will be presenting this draft at = IETF >> 87 in Berlin. Where there appears to be some amount of disagreement = is >> in the backward compatibility mechanisms. There are basically 3 = options >> (as well as subtle variants) >>=20 >>=20 >> 1. The approach in the draft, only allow adjacencies between >> routers supporting the extended encodings. Backward compatibility = would >> have to be provided with separate instances and topology. >>=20 >> 2. Both the current and extended versions of the LSAs are >> originated as long as there are routers not supporting the new = extended >> encodings at the respective flooding scope. This was the approach = taken >> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >> property of roughly doubling the size of the LSDB. >>=20 >> 3. Switch to the extended format only after all the routers at >> the flooding scope support it. Use OSPF demand circuit-like (RFC = 1793) >> signaling to determine whether or not all routers in the flooding = scope >> support the new format. The only potential problem with this approach = is >> a dynamics when a router not supporting the extended format = successively >> leaves and enters the routing domain. >>=20 >> What is the WG preference? I'm still in favor of the approach in the >> draft (#1) given the simplicity and stability properties. What we'd = lose >> in slowed deployment would be more than made up standardization and >> availability. Also, it would satisfy the homenet requirements we >> desperately need to satisfy. >>=20 >> Thanks, >> Acee >>=20 >>=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 From asmirnov@cisco.com Fri Jun 28 03:13:03 2013 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 3C0AB21F9EA9 for ; Fri, 28 Jun 2013 03:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Zd1P11NJ+Vke for ; Fri, 28 Jun 2013 03:12:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id EC01521F9ECC for ; Fri, 28 Jun 2013 03:12:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SACYSW001954; Fri, 28 Jun 2013 12:12:34 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SABl9i006010; Fri, 28 Jun 2013 12:12:03 +0200 (CEST) Message-ID: <51CD6163.5000204@cisco.com> Date: Fri, 28 Jun 2013 12:11:47 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 10:13:03 -0000 Hi Acee, Peter, IMO pure option 2 has its own problems. It is easy to imagine some future feature requiring all routers in the area understanding information the feature is sending in extended LSA. So if backward compatibility is preserved indefinitely then there is a risk of old-style-LSA router joining the domain and breaking the feature. That's why I think migration from the old-style LSA MUST be provided by the solution but solution should also define a point where backward compatibility is undesirable. Something like this: 0). Router is sending and using in SPF old-style LSA 1). Router is sending both old-style and extended LSAs but using only old 2). Router is sending both old-style and extended LSAs but using only extended 3). Router is sending and using only extended LSAs Steps 1 and 2 are in fact option 2 from the original email and at step 3 we arrived to option 1 but with gradual migration. Anton On 06/28/2013 11:44 AM, Acee Lindem wrote: > Hi Anton, Peter, > If I were to be convinced that #2 is the way to go, I like making it explicit configurations and only applicable to service provider and large enterprise deployments. That way, OSPFv3 implementations specifically for the homenet environments could omit it. > Thanks, > Acee > On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: > >> Hi Acee, >> while I appreciate developer's simplicity of option 1 this approach is good only for greenfield deployment. For any existing sizable OSPFv3 network its migration limitation may become an insurmountable obstacle. >> My preference is combination of options: start migration as option 2 and when migration is completed lock on 1. >> Benefits are that migration is possible; LSDB is doubled only for period of migration; and once migration is completed there is no need to worry about dynamics of old-style router entering the domain. >> Downside is relative complexity of implementation but that's the price to pay for simplicity of OSPFv3. BTW, entering and exiting migration may be manual (via configuration), so this mixed approach may be simpler to implement than 'pure' option 3. >> Said all that, individual products targeting greenfield deployment scenario may skip implementation of migration. Say, homenet may require support of extended LSAs from day 1. That would mean that homenet products will not be deployable in existing old-style-LSA networks - but that probably is not the intent anyway. >> >> Anton >> >> >> On 06/27/2013 10:18 PM, Acee Lindem wrote: >>> I don't think there is much disagreement that we need a direct way to >>> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF >>> 87 in Berlin. Where there appears to be some amount of disagreement is >>> in the backward compatibility mechanisms. There are basically 3 options >>> (as well as subtle variants) >>> >>> >>> 1. The approach in the draft, only allow adjacencies between >>> routers supporting the extended encodings. Backward compatibility would >>> have to be provided with separate instances and topology. >>> >>> 2. Both the current and extended versions of the LSAs are >>> originated as long as there are routers not supporting the new extended >>> encodings at the respective flooding scope. This was the approach taken >>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>> property of roughly doubling the size of the LSDB. >>> >>> 3. Switch to the extended format only after all the routers at >>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>> signaling to determine whether or not all routers in the flooding scope >>> support the new format. The only potential problem with this approach is >>> a dynamics when a router not supporting the extended format successively >>> leaves and enters the routing domain. >>> >>> What is the WG preference? I'm still in favor of the approach in the >>> draft (#1) given the simplicity and stability properties. What we'd lose >>> in slowed deployment would be more than made up standardization and >>> availability. Also, it would satisfy the homenet requirements we >>> desperately need to satisfy. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> _______________________________________________ >>> 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 Fri Jun 28 05:44:01 2013 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 9C0E921F9928 for ; Fri, 28 Jun 2013 05:44:01 -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 1+VinmvVdosH for ; Fri, 28 Jun 2013 05:43:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CE9CD21F9CA0 for ; Fri, 28 Jun 2013 05:41:25 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-25-51cd8473520e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2E.F5.31362.3748DC15; Fri, 28 Jun 2013 14:41:23 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 08:41:23 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOc9WjVWKceH6uu0OHrHh9bT44j5lLI4mAgAAHpYCAACnKgA== Date: Fri, 28 Jun 2013 12:41:22 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718E929@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> <51CD6163.5000204@cisco.com> In-Reply-To: <51CD6163.5000204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPn25xy9lAg5Z11hbTbk1ns2jZxmrR cu8eu8WO3e1sDiweU35vZPVYsuQnk8eHRRdYA5ijuGxSUnMyy1KL9O0SuDJm9rxmKejTqnja cp2pgbFFqYuRk0NCwETi1bxrrBC2mMSFe+vZuhi5OIQEjjJKXGv+DeUsZ5ToWN7ACFLFJqAj 8fzRP2YQW0RATWLz3U9A3RwczAJpEh9O1YKEhQVCJI7NfMoOURIqcfzjKqhyJ4lzm5rYQGwW AVWJS8degC3mFfCWuNeylwVi115GiUezTjKBJDgFNCVaTh0Fa2YEuu77qTVgcWYBcYlbT+Yz QVwtILFkz3lmCFtU4uXjf1DfKEssebKfBaJeR2LB7k9sELa1xOGP3ewQtrbEsoWvmSGOEJQ4 OfMJywRG8VlIVsxC0j4LSfssJO2zkLQvYGRdxchRWpxalptuZLiJERhzxyTYHHcwLvhkeYhR moNFSZx3g96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M8550vwtyT+zM8TJ6J71y8Tnp zZ9fJ/bNZU/cNNuxLX+C+Iqe6/lqLAUdPReCzko9v3bh3t9txYXX3yc4FayfqxsjZqia4qw0 441YaRz/N/V7UUmcf1pfRwk41yT6vN92+phTwMHtqwrdV715pHL62U/7gIedphcyRc8VuJdz +mduL+Qp3vBXiaU4I9FQi7moOBEAzqS7CYcCAAA= Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 12:44:01 -0000 Hi Anton, On Jun 28, 2013, at 6:11 AM, Anton Smirnov wrote: > Hi Acee, Peter, > IMO pure option 2 has its own problems. It is easy to imagine some futu= re feature requiring all routers in the area understanding information the = feature is sending in extended LSA. So if backward compatibility is preserv= ed indefinitely then there is a risk of old-style-LSA router joining the do= main and breaking the feature. Supporting the extended LSAs doesn't imply that the implementation will sup= port all the attendant TLVs. Backward compatibility and/or partial deployme= nt will need to be addressed in the documents defining the extensions using= the TLVs. The backward compatibility problem for future extensions can't b= e solved here - this is about extendible encoding for the base OSPFv3 fixed= format LSAs and nothing more. Thanks, Acee=20 > That's why I think migration from the old-style LSA MUST be provided by= the solution but solution should also define a point where backward compat= ibility is undesirable. > Something like this: > 0). Router is sending and using in SPF old-style LSA > 1). Router is sending both old-style and extended LSAs but using only old > 2). Router is sending both old-style and extended LSAs but using only ext= ended > 3). Router is sending and using only extended LSAs >=20 > Steps 1 and 2 are in fact option 2 from the original email and at step 3 = we arrived to option 1 but with gradual migration. >=20 > Anton >=20 >=20 > On 06/28/2013 11:44 AM, Acee Lindem wrote: >> Hi Anton, Peter, >> If I were to be convinced that #2 is the way to go, I like making it exp= licit configurations and only applicable to service provider and large ente= rprise deployments. That way, OSPFv3 implementations specifically for the h= omenet environments could omit it. >> Thanks, >> Acee >> On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: >>=20 >>> Hi Acee, >>> while I appreciate developer's simplicity of option 1 this approach i= s good only for greenfield deployment. For any existing sizable OSPFv3 netw= ork its migration limitation may become an insurmountable obstacle. >>> My preference is combination of options: start migration as option 2 = and when migration is completed lock on 1. >>> Benefits are that migration is possible; LSDB is doubled only for per= iod of migration; and once migration is completed there is no need to worry= about dynamics of old-style router entering the domain. >>> Downside is relative complexity of implementation but that's the pric= e to pay for simplicity of OSPFv3. BTW, entering and exiting migration may = be manual (via configuration), so this mixed approach may be simpler to imp= lement than 'pure' option 3. >>> Said all that, individual products targeting greenfield deployment sc= enario may skip implementation of migration. Say, homenet may require suppo= rt of extended LSAs from day 1. That would mean that homenet products will = not be deployable in existing old-style-LSA networks - but that probably is= not the intent anyway. >>>=20 >>> Anton >>>=20 >>>=20 >>> On 06/27/2013 10:18 PM, Acee Lindem wrote: >>>> I don't think there is much disagreement that we need a direct way to >>>> extend the base OSPFv3 LSAs and I will be presenting this draft at IET= F >>>> 87 in Berlin. Where there appears to be some amount of disagreement is >>>> in the backward compatibility mechanisms. There are basically 3 option= s >>>> (as well as subtle variants) >>>>=20 >>>>=20 >>>> 1. The approach in the draft, only allow adjacencies between >>>> routers supporting the extended encodings. Backward compatibility woul= d >>>> have to be provided with separate instances and topology. >>>>=20 >>>> 2. Both the current and extended versions of the LSAs are >>>> originated as long as there are routers not supporting the new extende= d >>>> encodings at the respective flooding scope. This was the approach take= n >>>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>>> property of roughly doubling the size of the LSDB. >>>>=20 >>>> 3. Switch to the extended format only after all the routers at >>>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>>> signaling to determine whether or not all routers in the flooding scop= e >>>> support the new format. The only potential problem with this approach = is >>>> a dynamics when a router not supporting the extended format successive= ly >>>> leaves and enters the routing domain. >>>>=20 >>>> What is the WG preference? I'm still in favor of the approach in the >>>> draft (#1) given the simplicity and stability properties. What we'd lo= se >>>> in slowed deployment would be more than made up standardization and >>>> availability. Also, it would satisfy the homenet requirements we >>>> desperately need to satisfy. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=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 >>=20 From ppsenak@cisco.com Fri Jun 28 06:29:24 2013 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 99A9B21F8449 for ; Fri, 28 Jun 2013 06:29:24 -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 t8g0GnEYnupt for ; Fri, 28 Jun 2013 06:29:19 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D121F8D0D for ; Fri, 28 Jun 2013 06:29:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SDTGSW025434 for ; Fri, 28 Jun 2013 15:29:16 +0200 (CEST) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.53]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SDTFLP013242; Fri, 28 Jun 2013 15:29:15 +0200 (CEST) Message-ID: <51CD8FAA.8090907@cisco.com> Date: Fri, 28 Jun 2013 15:29:14 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 13:29:24 -0000 Hi Acee, On 28.6.2013 11:44, Acee Lindem wrote: > Hi Anton, Peter, > If I were to be convinced that #2 is the way to go, I like making it explicit configurations and only applicable to service provider and large enterprise deployments. That way, OSPFv3 implementations specifically for the homenet environments could omit it. I'm fine with the config based approach. thanks, Peter > Thanks, > Acee > On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: > >> Hi Acee, >> while I appreciate developer's simplicity of option 1 this approach is good only for greenfield deployment. For any existing sizable OSPFv3 network its migration limitation may become an insurmountable obstacle. >> My preference is combination of options: start migration as option 2 and when migration is completed lock on 1. >> Benefits are that migration is possible; LSDB is doubled only for period of migration; and once migration is completed there is no need to worry about dynamics of old-style router entering the domain. >> Downside is relative complexity of implementation but that's the price to pay for simplicity of OSPFv3. BTW, entering and exiting migration may be manual (via configuration), so this mixed approach may be simpler to implement than 'pure' option 3. >> Said all that, individual products targeting greenfield deployment scenario may skip implementation of migration. Say, homenet may require support of extended LSAs from day 1. That would mean that homenet products will not be deployable in existing old-style-LSA networks - but that probably is not the intent anyway. >> >> Anton >> >> >> On 06/27/2013 10:18 PM, Acee Lindem wrote: >>> I don't think there is much disagreement that we need a direct way to >>> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF >>> 87 in Berlin. Where there appears to be some amount of disagreement is >>> in the backward compatibility mechanisms. There are basically 3 options >>> (as well as subtle variants) >>> >>> >>> 1. The approach in the draft, only allow adjacencies between >>> routers supporting the extended encodings. Backward compatibility would >>> have to be provided with separate instances and topology. >>> >>> 2. Both the current and extended versions of the LSAs are >>> originated as long as there are routers not supporting the new extended >>> encodings at the respective flooding scope. This was the approach taken >>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>> property of roughly doubling the size of the LSDB. >>> >>> 3. Switch to the extended format only after all the routers at >>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>> signaling to determine whether or not all routers in the flooding scope >>> support the new format. The only potential problem with this approach is >>> a dynamics when a router not supporting the extended format successively >>> leaves and enters the routing domain. >>> >>> What is the WG preference? I'm still in favor of the approach in the >>> draft (#1) given the simplicity and stability properties. What we'd lose >>> in slowed deployment would be more than made up standardization and >>> availability. Also, it would satisfy the homenet requirements we >>> desperately need to satisfy. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> _______________________________________________ >>> 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 mdubrovs@cisco.com Fri Jun 28 13:56:10 2013 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 B048D21F9CBC for ; Fri, 28 Jun 2013 13:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.445 X-Spam-Level: X-Spam-Status: No, score=-8.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 VbqIjr-Irhio for ; Fri, 28 Jun 2013 13:55:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 073F521F9C98 for ; Fri, 28 Jun 2013 13:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5431; q=dns/txt; s=iport; t=1372452945; x=1373662545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3xnkpy6o/yMbpqq6CjCYA9gCslc4BsToDbpj5OSdyew=; b=WTE5Nu9DrXAIsHhM+uWscbthUg++GYGrsUXeaq2bQ2IvmQ/9RmtruN7R 6pNknvuYAoPMIhn5DJpoXKuuuZlBCYOyMQKTdUNCZNICM/87XvIxprLdP tSl632D0eF0s7uaB/RQ+H01bDyFpE6wqsqYo71+LrG5HeDqjO2Cw0pgiN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFABz2zVGtJXG9/2dsb2JhbABbgwkySb8GgQoWdIIjAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiIBwy6RASPJTEHBoJ+YwOpCoMRgig X-IronPort-AV: E=Sophos;i="4.87,961,1363132800"; d="scan'208";a="225820762" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 20:55:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5SKtiEJ016289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 20:55:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 15:55:44 -0500 From: "Mike Dubrovskiy (mdubrovs)" To: "Peter Psenak (ppsenak)" , Acee Lindem Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOc3NrhDx5rAEZaU6K9RwM6LdMaplLF/4AgAAdEoCAAD7RAIAAJ0Xg Date: Fri, 28 Jun 2013 20:55:43 +0000 Message-ID: <534FD0D7D9E99740A077CE1A38EB79C3C54F1A@xmb-aln-x03.cisco.com> References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> <51CD8FAA.8090907@cisco.com> In-Reply-To: <51CD8FAA.8090907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 20:56:10 -0000 Hi guys, Does bellow looks like what you are saying ? Two mode of operation: RFC5340Compatibility is off (default) In this mode router originates only new types of LSAs. Router consider only new type of LSAs from other routers. Router does not establish adjacencies with old routers.=20 RFC5340Compatibility is on (non-default; need to be configured during trans= ition).=20 In this mode router originates both old and new types of LSA. Router prefers new type of LSA for SPF calculation. Router establish adjacencies with both types for routers. Old format router LSA has ExtendedFormatCapable flag set for the case when= corresponded new format LSA stuck somewhere When all old type LSAs in the router database have ExtendedFormatCapable f= lag, router flushes self-originated LSA in old format. The flag ExtendedFormatCapable should be propagated across area borders si= milar to OSPF demand circuit-like. Thank you, Mike > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Peter Psenak (ppsenak) > Sent: Friday, June 28, 2013 6:29 AM > To: Acee Lindem > Cc: OSPF@ietf.org > Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-exte= nd- > 00.txt >=20 > Hi Acee, >=20 > On 28.6.2013 11:44, Acee Lindem wrote: > > Hi Anton, Peter, > > If I were to be convinced that #2 is the way to go, I like making it ex= plicit > configurations and only applicable to service provider and large enterpri= se > deployments. That way, OSPFv3 implementations specifically for the > homenet environments could omit it. >=20 > I'm fine with the config based approach. >=20 > thanks, > Peter >=20 > > Thanks, > > Acee > > On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: > > > >> Hi Acee, > >> while I appreciate developer's simplicity of option 1 this approach= is good > only for greenfield deployment. For any existing sizable OSPFv3 network i= ts > migration limitation may become an insurmountable obstacle. > >> My preference is combination of options: start migration as option = 2 and > when migration is completed lock on 1. > >> Benefits are that migration is possible; LSDB is doubled only for p= eriod of > migration; and once migration is completed there is no need to worry abou= t > dynamics of old-style router entering the domain. > >> Downside is relative complexity of implementation but that's the pr= ice > to pay for simplicity of OSPFv3. BTW, entering and exiting migration may = be > manual (via configuration), so this mixed approach may be simpler to > implement than 'pure' option 3. > >> Said all that, individual products targeting greenfield deployment > scenario may skip implementation of migration. Say, homenet may require > support of extended LSAs from day 1. That would mean that homenet > products will not be deployable in existing old-style-LSA networks - but = that > probably is not the intent anyway. > >> > >> Anton > >> > >> > >> On 06/27/2013 10:18 PM, Acee Lindem wrote: > >>> I don't think there is much disagreement that we need a direct way > >>> to extend the base OSPFv3 LSAs and I will be presenting this draft > >>> at IETF > >>> 87 in Berlin. Where there appears to be some amount of disagreement > >>> is in the backward compatibility mechanisms. There are basically 3 > >>> options (as well as subtle variants) > >>> > >>> > >>> 1. The approach in the draft, only allow adjacencies > >>> between routers supporting the extended encodings. Backward > >>> compatibility would have to be provided with separate instances and > topology. > >>> > >>> 2. Both the current and extended versions of the LSAs are > >>> originated as long as there are routers not supporting the new > >>> extended encodings at the respective flooding scope. This was the > >>> approach taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", > >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable > >>> property of roughly doubling the size of the LSDB. > >>> > >>> 3. Switch to the extended format only after all the routers > >>> at the flooding scope support it. Use OSPF demand circuit-like (RFC > >>> 1793) signaling to determine whether or not all routers in the > >>> flooding scope support the new format. The only potential problem > >>> with this approach is a dynamics when a router not supporting the > >>> extended format successively leaves and enters the routing domain. > >>> > >>> What is the WG preference? I'm still in favor of the approach in the > >>> draft (#1) given the simplicity and stability properties. What we'd > >>> lose in slowed deployment would be more than made up > standardization > >>> and availability. Also, it would satisfy the homenet requirements we > >>> desperately need to satisfy. > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Fri Jun 28 14:17:51 2013 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 418E321F9CF8 for ; Fri, 28 Jun 2013 14:17:51 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JJhcjHgaQQnB for ; Fri, 28 Jun 2013 14:17:45 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF921F9CF5 for ; Fri, 28 Jun 2013 14:17:45 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-89-51cdfd7858f0 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 37.55.13034.87DFDC15; Fri, 28 Jun 2013 23:17:45 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 17:17:44 -0400 From: Acee Lindem To: Tanmoy Kundu Thread-Topic: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. Thread-Index: Ac5sGnznNwBh+oLtRnGrauEoRknkhf//8RyAgBBJ4IA= Date: Fri, 28 Jun 2013 21:17:44 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718F0AF@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4718F0AFeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPlG7l37OBBn0zOS12rdrHZtFy7x67 xa7r+xgtfj1ewuTA4rFz1l12jyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CV8WTKSqaC462M Fd/3rmBuYDxS0MXIySEhYCLx93s/C4QtJnHh3nq2LkYuDiGBo4wSjd+WMUE4yxklvjzfwgxS xSagI/H80T8wW0RAVaLx8l4mEJtZIFdiXd9bsAZhgZmMEifn/GUFcUQEZjFKPP51mx2iw0pi +rTjYN0sQN2fn98As3kFvCWaN7eATWIEuuP7qTVQU8Ulbj2ZzwRxn4DEkj3nmSFsUYmXj/+x gtiiAnoSbcfOsEPElSWWPNnPAtGbL3Hl2QcWiPmCEidnPmGZwCgyC8nYWUjKZiEpg4jrSCzY /YkNwtaWWLbwNTOMfebAY6hea4kDczYyIqtZwMixipGjtDi1LDfdyGATIzD2jkmw6e5g3PPS 8hCjNAeLkjjvKr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYxQRmf5jdqd+8V0TLLf7c Ngae3Ctnqm0T+X+v3/5/58KONXnXPsY9iv/1UkPskuHJ2z1pWXIWOtJ7GYzMBF1TFm+7+eOa yIc5zQ5Ctcssdqgs0Sn0WmQZ15CWdFK2c2bHnYfz6pUyvM5f2Goobb/9Tyyz8u33hVbrF91o b95qL+xwevGrFQ3ySizFGYmGWsxFxYkA6O0t7osCAAA= Cc: "OSPF@ietf.org" , Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. 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: Fri, 28 Jun 2013 21:17:51 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4718F0AFeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tanmoy that this is proper behavior. Thanks, Acee On Jun 18, 2013, at 10:00 AM, Tanmoy Kundu wrote: Hi Bharath, Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", h= ow did R2 sensed that R1 is down ? a. first possible option is dead timer expiry in R2. In that case R3 sh= ould also get the expiry soon and till that time the network won't converge= . isn't that expected? b. Another option is having BFD session between R1 and R2, hence it com= es to know. Why don't we run BFD between all the routers in the network ? A= s we know in OSPF the DR and BDR is not guaranteed. This typical scenario is due to the DR-other is with priority zero. But whe= n received hello packet from DR, both BDR and DR-Other should reset the dea= d timer. Even if we consider the link transmission delay and ASIC processin= g, the dead timer expiry difference between R2 and R3 should not be more th= an milisecond, isn't it ? * Is it right to trigger the NeighborChange event at R3? - I feel yes,= other than few typical scenarios the network will at least not be used, un= til its converged. If Nbr-chg event is not sent then all DR other feels tha= t DR is still active and the same will be used for forwarding the traffic. = If someone in the network sensed that DR/BDR is down, why don't tell others= immediately? * Is this transition from FULL to 2-WAY is expected? - As per RFC, DR = others should not be FULL with other routers than DR and BDR, hence YES. It= is expected. * Can DR-Others flap adjacency with BDR if DR down detection happens l= ater than reception of new Hello from the new DR? - * Intuitively, it may seem desirable to continue to be adjacent to a ne= ighbor as long as it is still DR or BDR. Is this a fair call? - As mentione= d above, its not fair to use a disturbed or unsettled network for forwardin= g. Due to backlink check failure the LAN wont be used for forwarding during= SPF. Hence as per me its proper behavior. Thanks, Tanmoy On Tue, Jun 18, 2013 at 5:26 PM, Bharath R > wrote: Hi, Please consider the scenario: R1(DR) R2(BDR) | I1 I2 | | | |______________________ | | | I3 | R3(DR-Other) Here: R1 is the DR. R2 is the BDR R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. Following are the is the set of operations and a sequence of events: 1. Interface I1 is disabled. So, DR connectivity is lost to the rest of = the network. 2. R2(The current BDR) detects the DR-down. 1. Declares itself the DR. 2. Declares BDR as NULL. 3. Sends out a Hello with DR as I2 interface address, and BDR as 0.0.0.0 1. R3(DR-Other) receives Hello from R2. As per, section 9.2 of RFC 2328: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Triggers a NeighborChange event, which in-turn results in a DR election at = R3. Please note that at this time R3 has not yet detected R1 down. Now result of DR-election at R3: DR: R1 BDR: 0.0.0.0 Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with R2(th= e new DR). Of course, on detection of DR down at R3, R3 will elect R2 as DR and then a= gain transition to ExStart, to Exchange to Full with R2. Can you please let me know: * Is it right to trigger the NeighborChange event at R3 ? * Is this transition from FULL to 2-WAY is expected? * Can DR-Others flap adjacency with BDR if DR down detection happens l= ater than reception of new Hello from the new DR? * Intuitively, it may seem desirable to continue to be adjacent to a ne= ighbor as long as it is still DR or BDR. Is this a fair call? Please correct me if I have missed out something. Thanks and Regards, Bharath R. _______________________________________________ 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 --_000_94A203EA12AECE4BA92D42DBFFE0AE4718F0AFeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <7FBA75F329CAC646983D11F7179E37DA@ericsson.com> Content-Transfer-Encoding: quoted-printable
I agree with Tanmoy that this is proper behavior. 
Thanks,
Acee
On Jun 18, 2013, at 10:00 AM, Tanmoy Kundu wrote:

Hi Bharath, 
Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", how did R2= sensed that R1 is down ?
    a.= first possible option is dead timer expiry in R2. In that case R3 sho= uld also get the expiry soon and till that time the network won't= converge. isn't that expected? 
    b.= Another option is having BFD session between R1 and R2, hence it comes to = know. Why don't we run BFD between all the routers in the network ? As we k= now in OSPF the DR and BDR is not guaranteed. 

This typical sce= nario is due to the DR-other is with priority zero. But when received hello= packet from DR, both BDR and DR-Other should reset the dead timer. Even if= we consider the link transmission delay and ASIC processing, the dead timer expiry difference between R2 and R3 sh= ould not be more than milisecond, isn't it ? 


  • Is  it right to trigger the NeighborCha= nge event at R3? - I feel yes, other than few typical scenarios the network= will at least not be used, until its converged. If Nbr-chg event is not se= nt then all DR other feels that DR is still active and the same will be used for forwarding the traffic. If someone in= the network sensed that DR/BDR is down, why don't tell others immediately?=  
  • Is this transition from FULL to 2-WAY&n= bsp; is expected? - As per RFC, DR others should not be FULL with other rou= ters than DR and BDR, hence YES. It is expected. 
  • Can DR-Others flap adjacency with BDR if DR down detection&n= bsp; happens later than reception of new Hello from  the new DR? -&nbs= p;
  • Intuitively, it may seem desirable to= continue to be adjacent to a neighbor as long as it is still DR or BDR. Is= this a fair call? - As mentioned above, its not fair to use a disturbed or= unsettled network for forwarding. Due to backlink check failure the LAN wont be used for forwarding during SPF. Hen= ce as per me its proper behavior. 


Thanks,
Tanmoy



On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juni= per.net> wrote:
Hi,
Please consider the scenario:
 
R1(DR)          &nbs= p;            &= nbsp;           &nbs= p;        R2(BDR)    = ;             <= /div>
|  I1          =             &nb= sp;            =             I2 =   |
|           &nb= sp;            =             &nb= sp;            =            |
|______________________ |
           &nbs= p;            &= nbsp;       |
           &nbs= p;            &= nbsp;       |  I3    = ;             <= /div>
           &nbs= p;            &= nbsp;       |
           &nbs= p;          R3(DR-Other)
 
Here:
R1 is the DR.
R2 is the BDR
R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/B= DR.
 
 
Following are the is the set of operations and a sequence of events:
 
  1. Interface I1 is disabled. So, DR connectivity is lost to the rest of th= e network.
  2. R2(The current BDR) detects the DR-down.
  1. Declares itself the DR.
  2. Declares BDR as NULL.
  3. Sends out= a Hello with DR as I2 interface address, and BDR as 0.0.0.0
  1. R3(DR-Other) receives Hello from R2.
As per, section 9.2 of RFC 2328:
 &nbs= p;          o   One = of the bidirectional neighbors is newly declaring
 &nbs= p;            &= nbsp; itself as either Designated Router or Backup Designated=
 &nbs= p;            &= nbsp; Router.  This is detected through examination of that
 &nbs= p;            &= nbsp; neighbor's Hello Packets.
 
 &nbs= p;          o   One = of the bidirectional neighbors is no longer
 &nbs= p;            &= nbsp; declaring itself as Designated Router, or is no longer<= /div>
 &nbs= p;            &= nbsp; declaring itself as Backup Designated Router.  This is
 &nbs= p;            &= nbsp; again detected through examination of that neighbor's
 &nbs= p;            &= nbsp; Hello Packets.
 
Triggers a NeighborChange e<= b>vent, which in-turn results in a DR election at R3.
Please note that at this time R3 has no= t yet detected R1 down.
Now result of DR-election at R3:
DR: R1
BDR: 0.0.0.0
Since R2 is no longer the BDR, R3 transiti= ons from FULL to 2-WAY with R2(the new DR).
Of course, on detection of DR down at R3, = R3 will elect R2 as DR and then again transition to ExStart, to Exchange to= Full with R2.
 
Can you please let me know:
  • Is  it right to trigger the NeighborChange event at R3 ?
  • I= s this transition from FULL to 2-WAY  is expected?
  • Can DR-Othe= rs flap adjacency with BDR if DR down detection  happens later than re= ception of new Hello from  the new DR?
  • Intuitively, it may seem desirable to continue to be adjacent to a= neighbor as long as it is still DR or BDR. Is this a fair call?
 
Please correct me if I have missed out something.
 
 
Thanks and Regards,
Bharath R.
 
 
 
 
 

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org= /mailman/listinfo/ospf

--_000_94A203EA12AECE4BA92D42DBFFE0AE4718F0AFeusaamb101ericsso_-- From acee.lindem@ericsson.com Fri Jun 28 14:19:52 2013 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 C0B9621F9D49 for ; Fri, 28 Jun 2013 14:19:52 -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=[AWL=0.000, 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 QqOWOh63joT6 for ; Fri, 28 Jun 2013 14:19:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41F2721F9D41 for ; Fri, 28 Jun 2013 14:19:46 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-f1-51cdfdf25fe8 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7C.65.13034.2FDFDC15; Fri, 28 Jun 2013 23:19:46 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 17:19:45 -0400 From: Acee Lindem To: Peter Psenak , Acee Lindem Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOdEU2VWKceH6uu0OHrHh9bT44jw== Date: Fri, 28 Jun 2013 21:19:45 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718F0E4@eusaamb101.ericsson.se> In-Reply-To: <51CD8FAA.8090907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <17411B86A2077A4195EB152EC134F324@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuO6nv2cDDdZ+1reYdms6m0XLNlaL lnv32C127G5nc2DxmPJ7I6vHkiU/mTw+LLrAGsAcxWWTkpqTWZZapG+XwJXxaOZDpoJOhYq5 M1qYGxh7pboYOTkkBEwkrp24zQRhi0lcuLeerYuRi0NI4CijxIvOu6wQznJGifOHzrGAVLEJ 6Eg8f/SPGcQWEXCW6Dh6FaiIg4NZwF3i7EsZkLCwQIjEsZlP2SFKQiWOf1wFVa4ncXTrelYQ m0VAVaJ/wjywGl4Bb4mti3sYQWxOAU2J7lPLwGoYgQ76fmoN2HHMAuISt57MhzpUQGLJnvPM ELaoxMvH/8DqRYHmtx07ww4RV5ZY8mQ/C0SvjsSC3Z/YIGxrib4rD6FmakssW/iaGeIGQYmT M5+wTGAUn4Vk3Swk7bOQtM9C0j4LSfsCRtZVjBylxalluelGBpsYgRF3TIJNdwfjnpeWhxil OViUxHlX6Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYrXlO7CH3d8Wp7/ZK8T6YI/gh WMr6eIXg+R7VCW/fVT9TbY5RuV3QcPPTn+81bxSef/Q07E7T8bBPi3e5KevV5bzurkPP9vkO Zz8+T/GVv7Wts8/+7DatpRo/w6ymnn72WeXo4gA5KdsdCdM8vpmdbtueWJCYvepv3GLLK9tf qR1ga+j+nLBLiaU4I9FQi7moOBEAqXCRFYYCAAA= Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 21:19:52 -0000 Great Peter - I'll discuss with my co-authors and update before cut-off. Thanks, Acee On 6/28/13 6:29 AM, "Peter Psenak" wrote: >Hi Acee, > >On 28.6.2013 11:44, Acee Lindem wrote: >> Hi Anton, Peter, >> If I were to be convinced that #2 is the way to go, I like making it >>explicit configurations and only applicable to service provider and >>large enterprise deployments. That way, OSPFv3 implementations >>specifically for the homenet environments could omit it. > >I'm fine with the config based approach. > >thanks, >Peter > >> Thanks, >> Acee >> On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: >> >>> Hi Acee, >>> while I appreciate developer's simplicity of option 1 this approach >>>is good only for greenfield deployment. For any existing sizable OSPFv3 >>>network its migration limitation may become an insurmountable obstacle. >>> My preference is combination of options: start migration as option >>>2 and when migration is completed lock on 1. >>> Benefits are that migration is possible; LSDB is doubled only for >>>period of migration; and once migration is completed there is no need >>>to worry about dynamics of old-style router entering the domain. >>> Downside is relative complexity of implementation but that's the >>>price to pay for simplicity of OSPFv3. BTW, entering and exiting >>>migration may be manual (via configuration), so this mixed approach may >>>be simpler to implement than 'pure' option 3. >>> Said all that, individual products targeting greenfield deployment >>>scenario may skip implementation of migration. Say, homenet may require >>>support of extended LSAs from day 1. That would mean that homenet >>>products will not be deployable in existing old-style-LSA networks - >>>but that probably is not the intent anyway. >>> >>> Anton >>> >>> >>> On 06/27/2013 10:18 PM, Acee Lindem wrote: >>>> I don't think there is much disagreement that we need a direct way to >>>> extend the base OSPFv3 LSAs and I will be presenting this draft at >>>>IETF >>>> 87 in Berlin. Where there appears to be some amount of disagreement is >>>> in the backward compatibility mechanisms. There are basically 3 >>>>options >>>> (as well as subtle variants) >>>> >>>> >>>> 1. The approach in the draft, only allow adjacencies between >>>> routers supporting the extended encodings. Backward compatibility >>>>would >>>> have to be provided with separate instances and topology. >>>> >>>> 2. Both the current and extended versions of the LSAs are >>>> originated as long as there are routers not supporting the new >>>>extended >>>> encodings at the respective flooding scope. This was the approach >>>>taken >>>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>>> property of roughly doubling the size of the LSDB. >>>> >>>> 3. Switch to the extended format only after all the routers at >>>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>>> signaling to determine whether or not all routers in the flooding >>>>scope >>>> support the new format. The only potential problem with this approach >>>>is >>>> a dynamics when a router not supporting the extended format >>>>successively >>>> leaves and enters the routing domain. >>>> >>>> What is the WG preference? I'm still in favor of the approach in the >>>> draft (#1) given the simplicity and stability properties. What we'd >>>>lose >>>> in slowed deployment would be more than made up standardization and >>>> availability. Also, it would satisfy the homenet requirements we >>>> desperately need to satisfy. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Jun 28 14:23:12 2013 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 4E27521F9D72 for ; Fri, 28 Jun 2013 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 S3DdbjEg2ehb for ; Fri, 28 Jun 2013 14:23:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2621F9D53 for ; Fri, 28 Jun 2013 14:23:04 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-22-51cdfeb1b9a6 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C6.16.31362.2BEFDC15; Fri, 28 Jun 2013 23:22:58 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 17:22:57 -0400 From: Acee Lindem To: "Mike Dubrovskiy (mdubrovs)" , "Peter Psenak (ppsenak)" , Acee Lindem Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt Thread-Index: AQHOdEWoKjxMLOIblEqRETa+hNuhlg== Date: Fri, 28 Jun 2013 21:22:57 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718F0FB@eusaamb101.ericsson.se> In-Reply-To: <534FD0D7D9E99740A077CE1A38EB79C3C54F1A@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <2754AB3FD60EE84E822EAA88A1DE55D5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPuO6mf2cDDY6eEbeYdms6m8XDX2vY LFru3WO32LG7nc2BxWPK742sHkuW/GTy+LDoAmsAcxSXTUpqTmZZapG+XQJXxqreX6wF9/Qq 3k6/xdjA+Fa1i5GTQ0LAROLa8uVsELaYxIV764FsLg4hgaOMElfPH2CEcJYzShx9dp0ZpIpN QEfi+aN/zCAJEYEWRokjOx+wgiSYBZQl/h5azwJiCwuESByb+ZQdxBYRCJU4/nEVM4StJ/Gs 7yZYnEVAVWLvhg6wOK+At8TrHefB5nAC2XPW3gOrYQQ66fupNUwQ88Ulbj2ZzwRxqoDEkj3n mSFsUYmXj/+B9YoCzW87doYdIq4sseTJfhaIXh2JBbs/sUHY1hJ9S58yQ9jaEssWvoa6QVDi 5MwnLBMYxWchWTcLSfssJO2zkLTPQtK+gJF1FSNHaXFqWW66keEmRmDcHZNgc9zBuOCT5SFG aQ4WJXHeDXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwptyv4Sp9uyZwnUTZlCnJFcUn zCb77uCc4XuhLMnceoK8kaxIgtkWc8PPK3d7TntplHpic310356Fs6eonWY5fIsjLriIp7fi 3sm0A/s6hdtvnZwm5pgsPMt0i6ea4ltPpZou9z6RbyHXtknZTpzodzQxbdW3wA+Vj9SfskQY J7yYcGwlL1OlEktxRqKhFnNRcSIAm2DRVokCAAA= Cc: "OSPF@ietf.org" Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Fri, 28 Jun 2013 21:23:12 -0000 Hi Mike,=20 My first thought is that we'd make the dual LSA origination base on configuration rather than based on the RFC 1793-esque signaling. I will need to discuss with my co-authors. Thanks, Acee=20 On 6/28/13 1:55 PM, "Mike Dubrovskiy (mdubrovs)" wrote: >Hi guys, > >Does bellow looks like what you are saying ? > >Two mode of operation: > >RFC5340Compatibility is off (default) > >In this mode router originates only new types of LSAs. >Router consider only new type of LSAs from other routers. >Router does not establish adjacencies with old routers. > >RFC5340Compatibility is on (non-default; need to be configured during >transition).=20 > >In this mode router originates both old and new types of LSA. >Router prefers new type of LSA for SPF calculation. >Router establish adjacencies with both types for routers. > >Old format router LSA has ExtendedFormatCapable flag set for the case >when corresponded new format LSA stuck somewhere >When all old type LSAs in the router database have ExtendedFormatCapable >flag, router flushes self-originated LSA in old format. >The flag ExtendedFormatCapable should be propagated across area borders >similar to OSPF demand circuit-like. > >Thank you, >Mike > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >> Peter Psenak (ppsenak) >> Sent: Friday, June 28, 2013 6:29 AM >> To: Acee Lindem >> Cc: OSPF@ietf.org >> Subject: Re: [OSPF] OSPFv3 LSA Extendibility - >>draft-acee-ospfv3-lsa-extend- >> 00.txt >>=20 >> Hi Acee, >>=20 >> On 28.6.2013 11:44, Acee Lindem wrote: >> > Hi Anton, Peter, >> > If I were to be convinced that #2 is the way to go, I like making it >>explicit >> configurations and only applicable to service provider and large >>enterprise >> deployments. That way, OSPFv3 implementations specifically for the >> homenet environments could omit it. >>=20 >> I'm fine with the config based approach. >>=20 >> thanks, >> Peter >>=20 >> > Thanks, >> > Acee >> > On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote: >> > >> >> Hi Acee, >> >> while I appreciate developer's simplicity of option 1 this >>approach is good >> only for greenfield deployment. For any existing sizable OSPFv3 network >>its >> migration limitation may become an insurmountable obstacle. >> >> My preference is combination of options: start migration as >>option 2 and >> when migration is completed lock on 1. >> >> Benefits are that migration is possible; LSDB is doubled only for >>period of >> migration; and once migration is completed there is no need to worry >>about >> dynamics of old-style router entering the domain. >> >> Downside is relative complexity of implementation but that's the >>price >> to pay for simplicity of OSPFv3. BTW, entering and exiting migration >>may be >> manual (via configuration), so this mixed approach may be simpler to >> implement than 'pure' option 3. >> >> Said all that, individual products targeting greenfield deployment >> scenario may skip implementation of migration. Say, homenet may require >> support of extended LSAs from day 1. That would mean that homenet >> products will not be deployable in existing old-style-LSA networks - >>but that >> probably is not the intent anyway. >> >> >> >> Anton >> >> >> >> >> >> On 06/27/2013 10:18 PM, Acee Lindem wrote: >> >>> I don't think there is much disagreement that we need a direct way >> >>> to extend the base OSPFv3 LSAs and I will be presenting this draft >> >>> at IETF >> >>> 87 in Berlin. Where there appears to be some amount of disagreement >> >>> is in the backward compatibility mechanisms. There are basically 3 >> >>> options (as well as subtle variants) >> >>> >> >>> >> >>> 1. The approach in the draft, only allow adjacencies >> >>> between routers supporting the extended encodings. Backward >> >>> compatibility would have to be provided with separate instances and >> topology. >> >>> >> >>> 2. Both the current and extended versions of the LSAs are >> >>> originated as long as there are routers not supporting the new >> >>> extended encodings at the respective flooding scope. This was the >> >>> approach taken in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >> >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >> >>> property of roughly doubling the size of the LSDB. >> >>> >> >>> 3. Switch to the extended format only after all the routers >> >>> at the flooding scope support it. Use OSPF demand circuit-like (RFC >> >>> 1793) signaling to determine whether or not all routers in the >> >>> flooding scope support the new format. The only potential problem >> >>> with this approach is a dynamics when a router not supporting the >> >>> extended format successively leaves and enters the routing domain. >> >>> >> >>> What is the WG preference? I'm still in favor of the approach in the >> >>> draft (#1) given the simplicity and stability properties. What we'd >> >>> lose in slowed deployment would be more than made up >> standardization >> >>> and availability. Also, it would satisfy the homenet requirements we >> >>> desperately need to satisfy. >> >>> >> >>> Thanks, >> >>> Acee >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> > >> > >> > >>=20 >>=20 >> _______________________________________________ >> 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 mjbarnes@cisco.com Fri Jun 28 17:34:00 2013 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 2E78F21F9B95 for ; Fri, 28 Jun 2013 17:33:57 -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 owB1S3JJtlcn for ; Fri, 28 Jun 2013 17:33:43 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9712321F9B85 for ; Fri, 28 Jun 2013 17:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3786; q=dns/txt; s=iport; t=1372466023; x=1373675623; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=el0O0OIag9rIhCTWzIf3VFzeyfYl93rmUmEV3odbSBQ=; b=SeN55rsSmOmATGBuVn9lTEdob1AtVTx7tUEtHCoQd18akQaOx1RIrzL1 3wlj7p1afQRrAqRGtIpOHh/aO0ihYnB24ynPQigtHxOY4LrPTiD3g2S1X dpzaykoLj9+fm6bXCZnvW+9pGt9t8jDwnJijdK28N58YMUX0flNqotHkT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEcpzlGrRDoG/2dsb2JhbABbgwkyv1SBChZ0giMBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTATBgIBAYgKDbo7BI9dg2cDiSKOI4YhiySDMRw X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="84581600" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 Jun 2013 00:33:42 +0000 Received: from [10.21.121.78] (sjc-vpn6-334.cisco.com [10.21.121.78]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5T0XfSn018358 for ; Sat, 29 Jun 2013 00:33:41 GMT Message-ID: <51CE2B65.7050206@cisco.com> Date: Fri, 28 Jun 2013 17:33:41 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ospf@ietf.org References: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.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: Sat, 29 Jun 2013 00:34:00 -0000 Hi Acee, Here are some ideas you can consider to reduce the LSDB size and/or the complexity of the code. You could require that any data advertised in an old LSA MUST also be advertised in a new LSA. That would reduce the complexity (since all old LSAs could be ignored) at the expense of LSDB size. Alternately, you could allow a router an option of advertising the new LSA when it must advertise the old LSA. So in the case that the new LSA does not provide any additional information, and the router must originate the old LSA regardless, then the LSDB size is reduced without any loss of information, but obviously at the cost of complexity. If it is optional for a router to advertise a new LSA as above, then it would be helpful, to reduce code complexity, to require that if the router does advertise both old and new LSAs, then a new LSA with the same type and LSID as the old must contain a superset of the information advertised in the old LSA. This way other routers can know when they can safely ignore the old LSA. Regards, Michael On 06/27/2013 01:53 PM, Acee Lindem wrote: > Peter, Michael, > I guess you guys have considered the complexity this adds. For example, > you now need rules for LSDB entry selection during the SPF given that the > calculation will now have to handle a mix of extended and non-extended > LSAs. #2 is actually my least favorite of the three options given the > complexity it burdens us with forever. > > Acee > > On 6/27/13 1:43 PM, "Peter Psenak" wrote: > >> Hi Acee, >> >> my preference is option (2). >> >> thanks, >> Peter >> >> >> On 27.6.2013 22:18, Acee Lindem wrote: >>> I don't think there is much disagreement that we need a direct way to >>> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF >>> 87 in Berlin. Where there appears to be some amount of disagreement is >>> in the backward compatibility mechanisms. There are basically 3 options >>> (as well as subtle variants) >>> >>> >>> 1. The approach in the draft, only allow adjacencies between >>> routers supporting the extended encodings. Backward compatibility would >>> have to be provided with separate instances and topology. >>> >>> 2. Both the current and extended versions of the LSAs are >>> originated as long as there are routers not supporting the new extended >>> encodings at the respective flooding scope. This was the approach taken >>> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)", >>> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable >>> property of roughly doubling the size of the LSDB. >>> >>> 3. Switch to the extended format only after all the routers at >>> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793) >>> signaling to determine whether or not all routers in the flooding scope >>> support the new format. The only potential problem with this approach is >>> a dynamics when a router not supporting the extended format successively >>> leaves and enters the routing domain. >>> >>> What is the WG preference? I'm still in favor of the approach in the >>> draft (#1) given the simplicity and stability properties. What we'd lose >>> in slowed deployment would be more than made up standardization and >>> availability. Also, it would satisfy the homenet requirements we >>> desperately need to satisfy. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> _______________________________________________ >>> 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 >