From acee.lindem@ericsson.com Mon Mar 1 06:36:49 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E4A28C22B for ; Mon, 1 Mar 2010 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UstGomcoSF8z for ; Mon, 1 Mar 2010 06:36:48 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D1D5728C1AD for ; Mon, 1 Mar 2010 06:36:47 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o21EX7qA009070; Mon, 1 Mar 2010 08:38:43 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 1 Mar 2010 09:35:27 -0500 From: Acee Lindem To: Rajesh Shetty Date: Mon, 1 Mar 2010 09:35:24 -0500 Thread-Topic: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] Thread-Index: Acq5TG7nXCPLQUR9SPuRENLsdUdYKg== Message-ID: References: <4B88662F.5050605@cisco.com> <000001cab905$311adea0$1f01120a@china.huawei.com> In-Reply-To: <000001cab905$311adea0$1f01120a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , Acee Lindem Subject: Re: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 14:36:49 -0000 Hi Rajesh, What situation are you talking about? If it is when the R-bit is set, I don= 't see why there would be any problem with the Intra-area-prefix-LSA corres= ponding to the Network-LSA.=20 Acee On Mar 1, 2010, at 1:05 AM, Rajesh Shetty wrote: >=20 > Dear All, >=20 > Irrespective of whether V is root or not > V's Intra Area Prefix with reference type Router will get installed to th= e > RIB. But V's Intra Area Prefix with reference type Network will not get > installed, whether this behavior is as expected? >=20 > Thanks > Rajesh >=20 >=20 > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender= by > phone or email immediately and delete it! >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Michael Barnes > Sent: Saturday, February 27, 2010 5:54 AM > To: Acee Lindem > Cc: ospf@ietf.org > Subject: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata > Reported] RFC5340 (2046)] >=20 > Hi Acee, >=20 > Another question regarding the R-bit. If V is the root of the SPF tree=20 > (e.g. it is the router doing the SPF) with the current rules it will not= =20 > install any OSPF routes into its own RIB. I don't think this is really=20 > the behavior that is desired. If V is the root then don't we want to=20 > ignore the R-bit? >=20 > Thanks, > Michael >=20 >=20 > -------- Original Message -------- > Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046) > Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST) > From: RFC Errata System > To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com,=20 > acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com,=20 > acee@redback.com, akr@cisco.com > CC: ospf@ietf.org, rfc-editor@rfc-editor.org >=20 >=20 > The following errata report has been submitted for RFC5340, > "OSPF for IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5340&eid=3D2046 >=20 > -------------------------------------- > Type: Technical > Reported by: Acee Lindem >=20 > Section: 4.8.1 >=20 > Original Text > ------------- > o In Step 2, when a router Vertex V has just been added to the > shortest-path tree, there may be multiple LSAs associated with the > router. All router-LSAs with the Advertising Router set to V's > OSPF Router ID MUST be processed as an aggregate, treating them as > fragments of a single large router-LSA. The Options field and the >=20 >=20 >=20 >=20 > Coltun, et al. Standards Track [Page 45] > ^L > RFC 5340 OSPF for IPv6 July 2008 >=20 >=20 > router type bits (bits Nt, V, E, and B) should always be taken > from the router-LSA with the smallest Link State ID. >=20 > o Step 2a is not needed in IPv6, as there are no longer stub network > links in router-LSAs. >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is > not set in the LSA options, the transit link W is ignored and V's > next link is examined. >=20 >=20 > Corrected Text > -------------- > o In Step 2, when a router Vertex V has just been added to the > shortest-path tree and the router-LSA R-bit is not set in the > LSA options, Vertex V's links are ignored and the next vertex on > the candidate list should be examined as described in Step 3. >=20 >=20 >=20 > Coltun, et al. Standards Track [Page 45] > ^L > RFC 5340 OSPF for IPv6 July 2008 >=20 >=20 > o Also In Step 2, when a router Vertex V has just been added to the > shortest-path tree, there may be multiple LSAs associated with the > router. All router-LSAs with the Advertising Router set to V's > OSPF Router ID MUST be processed as an aggregate, treating them as > fragments of a single large router-LSA. The Options field and the > router type bits (bits Nt, V, E, and B) should always be taken > from the router-LSA with the smallest Link State ID. >=20 > o Step 2a is not needed in IPv6, as there are no longer stub network > links in router-LSAs. >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit is not set > in the LSA options, the transit link to W is ignored and V's next > link is examined. >=20 >=20 >=20 > Notes > ----- > This changes reflects the fact that the R-bit and the V6-bit should not=20 > be handled identically. The R-bit allows the router to participate in=20 > the IPv6 unicast topology but does not allow transit traffic. The V6-bit= =20 > doesn't allow either. This problem was pointed out by Balaji Ganesh. >=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 > -------------------------------------- > RFC5340 (draft-ietf-ospf-ospfv3-update-23) > -------------------------------------- > Title : OSPF for IPv6 > Publication Date : July 2008 > Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem > Category : PROPOSED 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 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Mar 1 08:06:28 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9B028C3E9 for ; Mon, 1 Mar 2010 08:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd6GOJAhPvlI for ; Mon, 1 Mar 2010 08:06:27 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 9DE2D28C2F9 for ; Mon, 1 Mar 2010 08:06:27 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o21G0AY5029193; Mon, 1 Mar 2010 10:07:37 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 1 Mar 2010 11:04:08 -0500 From: Acee Lindem To: Michael Barnes Date: Mon, 1 Mar 2010 11:04:06 -0500 Thread-Topic: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] Thread-Index: Acq5WNLsU5eu5tAUQ8+I2H02fhyD0Q== Message-ID: References: <4B88662F.5050605@cisco.com> In-Reply-To: <4B88662F.5050605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:06:29 -0000 Hi Michael, I agree - hopefully nobody has implemented this yet :^). Here is an update = to the errata for review. I used the same terminology as is used in RFC 232= 8's section 16.1, step 1.=20 *** rfc5340.txt 2010-01-31 15:28:35.000000000 -0500 --- rfc5340.txt.errata 2010-03-01 10:56:04.000000000 -0500 *************** *** 2510,2521 **** for a transit network is a combination of the Interface ID and OSPF Router ID of the network's Designated Router. =20 ! o In Step 2, when a router Vertex V has just been added to the ! shortest-path tree, there may be multiple LSAs associated with the ! router. All router-LSAs with the Advertising Router set to V's ! OSPF Router ID MUST be processed as an aggregate, treating them as ! fragments of a single large router-LSA. The Options field and the !=20 =20 =20 =20 --- 2510,2520 ---- for a transit network is a combination of the Interface ID and OSPF Router ID of the network's Designated Router. =20 ! o In Step 2, when a router Vertex V other than the root (which is ! the router doing the calculation) has just been added to the ! shortest-path tree and the router-LSA R-bit is not set in the=20 ! LSA options, Vertex V's links are ignored and the next vertex on ! the candidate list should be examined as described in Step 3.=20 =20 =20 =20 *************** *** 2524,2538 **** RFC 5340 OSPF for IPv6 July 2008 =20 =20 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. =20 o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. =20 ! o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is ! not set in the LSA options, the transit link W is ignored and V's ! next link is examined. =20 o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising --- 2523,2542 ---- RFC 5340 OSPF for IPv6 July 2008 =20 =20 + o Also In Step 2, when a router Vertex V has just been added to the + shortest-path tree, there may be multiple LSAs associated with the + router. All router-LSAs with the Advertising Router set to V's + OSPF Router ID MUST be processed as an aggregate, treating them as + fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. =20 o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. =20 ! o In Step 2b, if W is a router and the router-LSA V6-bit is not set ! in the LSA options, the transit link to W is ignored and V's next ! link is examined. =20 o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising Thanks, Acee On Feb 26, 2010, at 7:24 PM, Michael Barnes wrote: > Hi Acee, >=20 > Another question regarding the R-bit. If V is the root of the SPF tree=20 > (e.g. it is the router doing the SPF) with the current rules it will not= =20 > install any OSPF routes into its own RIB. I don't think this is really=20 > the behavior that is desired. If V is the root then don't we want to=20 > ignore the R-bit? >=20 > Thanks, > Michael >=20 >=20 > -------- Original Message -------- > Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046) > Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST) > From: RFC Errata System > To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com,=20 > acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com,=20 > acee@redback.com, akr@cisco.com > CC: ospf@ietf.org, rfc-editor@rfc-editor.org >=20 >=20 > The following errata report has been submitted for RFC5340, > "OSPF for IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5340&eid=3D2046 >=20 > -------------------------------------- > Type: Technical > Reported by: Acee Lindem >=20 > Section: 4.8.1 >=20 > Original Text > ------------- > o In Step 2, when a router Vertex V has just been added to the > shortest-path tree, there may be multiple LSAs associated with the > router. All router-LSAs with the Advertising Router set to V's > OSPF Router ID MUST be processed as an aggregate, treating them as > fragments of a single large router-LSA. The Options field and the >=20 >=20 >=20 >=20 > Coltun, et al. Standards Track [Page 45] > ^L > RFC 5340 OSPF for IPv6 July 2008 >=20 >=20 > router type bits (bits Nt, V, E, and B) should always be taken > from the router-LSA with the smallest Link State ID. >=20 > o Step 2a is not needed in IPv6, as there are no longer stub network > links in router-LSAs. >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is > not set in the LSA options, the transit link W is ignored and V's > next link is examined. >=20 >=20 > Corrected Text > -------------- > o In Step 2, when a router Vertex V has just been added to the > shortest-path tree and the router-LSA R-bit is not set in the > LSA options, Vertex V's links are ignored and the next vertex on > the candidate list should be examined as described in Step 3. >=20 >=20 >=20 > Coltun, et al. Standards Track [Page 45] > ^L > RFC 5340 OSPF for IPv6 July 2008 >=20 >=20 > o Also In Step 2, when a router Vertex V has just been added to the > shortest-path tree, there may be multiple LSAs associated with the > router. All router-LSAs with the Advertising Router set to V's > OSPF Router ID MUST be processed as an aggregate, treating them as > fragments of a single large router-LSA. The Options field and the > router type bits (bits Nt, V, E, and B) should always be taken > from the router-LSA with the smallest Link State ID. >=20 > o Step 2a is not needed in IPv6, as there are no longer stub network > links in router-LSAs. >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit is not set > in the LSA options, the transit link to W is ignored and V's next > link is examined. >=20 >=20 >=20 > Notes > ----- > This changes reflects the fact that the R-bit and the V6-bit should not=20 > be handled identically. The R-bit allows the router to participate in=20 > the IPv6 unicast topology but does not allow transit traffic. The V6-bit= =20 > doesn't allow either. This problem was pointed out by Balaji Ganesh. >=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 > -------------------------------------- > RFC5340 (draft-ietf-ospf-ospfv3-update-23) > -------------------------------------- > Title : OSPF for IPv6 > Publication Date : July 2008 > Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem > Category : PROPOSED 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 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Wed Mar 3 11:05:02 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4173A8DF6 for ; Wed, 3 Mar 2010 11:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq43U2r+jh9Y for ; Wed, 3 Mar 2010 11:05:00 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id F01CB3A8DF3 for ; Wed, 3 Mar 2010 11:04:59 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o23J7OHQ014333 for ; Wed, 3 Mar 2010 13:07:26 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 3 Mar 2010 14:04:57 -0500 From: Acee Lindem To: "ospf@ietf.org" Date: Wed, 3 Mar 2010 14:04:55 -0500 Thread-Topic: request for help in developing a tool that may be helpful to WG chairs Thread-Index: Acq7BGn91u6f1RFCTH6OVQvLvqWIXQ== Message-ID: <3E02720E-7589-4FE6-8665-C44A1297CAF8@ericsson.com> References: <20100303153619.1C185530773@newdev.eecs.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Fwd: request for help in developing a tool that may be helpful to WG chairs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 19:05:02 -0000 FYI... Begin forwarded message: From: "Scott O. Bradner" > Date: March 3, 2010 10:36:19 AM EST To: "wgchairs@ietf.org" > Subject: request for help in developing a tool that may be helpful to WG ch= airs IETF working group chairs; We are developing an open-source tool for monitoring the status and progress of conflicts in on-line working groups (WG). The tool works by analyzing the WG mailing list. When developed, this tool should be helpful to WG chairs trying to understand the status of WG discussions (how close to consensus is the WG, what is the distribution of participation, etc). As part of the development process we have been using a prototype tool to analyze IETF WG mailing list archives to determine the amount of conflict and how effective this conflict is being (has been) resolved. As the first step, we need to understand the relationship between the conflicts in a working group and the structure of the communication network in that group. While having conflicts is not necessarily a bad thing for a working group effort, some conflicts can escalate into disasters. We are interested in finding the communication patterns related to the evolution of group conflicts. Results from this study will provide the base for the development of the tool that helps working group chairs to decide when to intervene with an internal conflict before it becomes irreversibly negative as well as being a tool that may help determine where there is consensus on a particular topic. We would like your help in understanding the level of conflicts within your working groups and how the conflicts affect productivity and group members=E2=80=99 perception on the working group. It will be greatly apprec= iated if you could ask your WG members to anonymously fill a short survey at https://spreadsheets.google.com/viewform?hl=3Den&formkey=3DdExTbEU5QmRncnhF= bjhQUVR4bzBGMEE6MA Thank you! Best Regards, Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin From cfinss@dial.pipex.com Sat Mar 6 12:38:16 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E143A900F for ; Sat, 6 Mar 2010 12:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0yXJuQTSiSV for ; Sat, 6 Mar 2010 12:38:15 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 198303A8B56 for ; Sat, 6 Mar 2010 12:38:14 -0800 (PST) X-Trace: 188699027/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.137/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.137 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAIAAtMkks+vGSJ/2dsb2JhbACBeoVaiRqLUbYlDYRrBA X-IronPort-AV: E=Sophos;i="4.49,595,1262563200"; d="scan'208";a="188699027" X-IP-Direction: IN Received: from 1cust137.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.137]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2010 20:38:16 +0000 Message-ID: <00b701cabd64$6657f4a0$0601a8c0@allison> From: "tom.petch" To: "Acee Lindem" , References: <20100303153619.1C185530773@newdev.eecs.harvard.edu> <3E02720E-7589-4FE6-8665-C44A1297CAF8@ericsson.com> Date: Sat, 6 Mar 2010 20:36:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [OSPF] Fwd: request for help in developing a tool that may be helpful to WG chairs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 20:38:16 -0000 Acee I am confused. Can we only answer about OSPF or can we choose which group? Only OSPF has been singularly dispute free and not worth answering about, whereas I can think of major and obstructive conflict in at least three WG in the past 12 months which would be far better to talk about. Tom Petch ----- Original Message ----- From: "Acee Lindem" To: Sent: Wednesday, March 03, 2010 8:04 PM Subject: [OSPF] Fwd: request for help in developing a tool that may be helpful to WG chairs FYI... Begin forwarded message: From: "Scott O. Bradner" > Date: March 3, 2010 10:36:19 AM EST To: "wgchairs@ietf.org" > Subject: request for help in developing a tool that may be helpful to WG chairs IETF working group chairs; We are developing an open-source tool for monitoring the status and progress of conflicts in on-line working groups (WG). The tool works by analyzing the WG mailing list. When developed, this tool should be helpful to WG chairs trying to understand the status of WG discussions (how close to consensus is the WG, what is the distribution of participation, etc). As part of the development process we have been using a prototype tool to analyze IETF WG mailing list archives to determine the amount of conflict and how effective this conflict is being (has been) resolved. As the first step, we need to understand the relationship between the conflicts in a working group and the structure of the communication network in that group. While having conflicts is not necessarily a bad thing for a working group effort, some conflicts can escalate into disasters. We are interested in finding the communication patterns related to the evolution of group conflicts. Results from this study will provide the base for the development of the tool that helps working group chairs to decide when to intervene with an internal conflict before it becomes irreversibly negative as well as being a tool that may help determine where there is consensus on a particular topic. We would like your help in understanding the level of conflicts within your working groups and how the conflicts affect productivity and group members’ perception on the working group. It will be greatly appreciated if you could ask your WG members to anonymously fill a short survey at https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQUVR4b zBGMEE6MA Thank you! Best Regards, Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Sat Mar 6 17:26:10 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6A228C225 for ; Sat, 6 Mar 2010 17:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB2dFPwS-rxS for ; Sat, 6 Mar 2010 17:26:09 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D9E0528C112 for ; Sat, 6 Mar 2010 17:26:08 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o271Shew010254; Sat, 6 Mar 2010 19:28:44 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sat, 6 Mar 2010 20:26:07 -0500 From: Acee Lindem To: "tom.petch" Date: Sat, 6 Mar 2010 20:26:05 -0500 Thread-Topic: [OSPF] Fwd: request for help in developing a tool that may be helpful to WG chairs Thread-Index: Acq9lSjE3yorQzH8Q3KMxRFKSy/TRw== Message-ID: <2948AB65-B20E-4AC5-9C39-4C79C81947CB@ericsson.com> References: <20100303153619.1C185530773@newdev.eecs.harvard.edu> <3E02720E-7589-4FE6-8665-C44A1297CAF8@ericsson.com> <00b701cabd64$6657f4a0$0601a8c0@allison> In-Reply-To: <00b701cabd64$6657f4a0$0601a8c0@allison> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Fwd: request for help in developing a tool that may be helpful to WG chairs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 01:26:10 -0000 Hi Tom, You can definitely answer with respect to another WG as this was an IETF wi= de query. Note that OSPF has not been immune to conflict as we were not able to agree= on a single mechanism to reduce flooding in MANET networks.=20 Also, we could probably benefit from some more conflict on the base specifi= cations and extensions. While it doesn't seem the router vendors have any p= roblems with interoperable implementations, it seems the test tool vendors = have many times misinterpreted the specifications and released invalid test= s. It would be beneficial if the test tool vendors would review the specifi= cations during the standardization process. =20 Thanks, Acee On Mar 6, 2010, at 2:36 PM, tom.petch wrote: > Acee >=20 > I am confused. >=20 > Can we only answer about OSPF or can we choose which group? Only OSPF ha= s been > singularly dispute free and not worth answering about, whereas I can thin= k of > major and obstructive conflict in at least three WG in the past 12 months= which > would be far better to talk about. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Wednesday, March 03, 2010 8:04 PM > Subject: [OSPF] Fwd: request for help in developing a tool that may be he= lpful > to WG chairs >=20 >=20 > FYI... >=20 > Begin forwarded message: >=20 > From: "Scott O. Bradner" > > Date: March 3, 2010 10:36:19 AM EST > To: "wgchairs@ietf.org" > > > Subject: request for help in developing a tool that may be helpful to WG = chairs >=20 > IETF working group chairs; >=20 > We are developing an open-source tool for monitoring the status and > progress of conflicts in on-line working groups (WG). The tool works by > analyzing the WG mailing list. When developed, this tool should be > helpful to WG chairs trying to understand the status of WG discussions > (how close to consensus is the WG, what is the distribution of > participation, etc). >=20 > As part of the development process we have been using a prototype tool > to analyze IETF WG mailing list archives to determine the amount of > conflict and how effective this conflict is being (has been) resolved. > As the first step, we need to understand the relationship between the > conflicts in a working group and the structure of the communication > network in that group. While having conflicts is not necessarily a bad > thing for a working group effort, some conflicts can escalate into > disasters. We are interested in finding the communication patterns > related to the evolution of group conflicts. Results from this study > will provide the base for the development of the tool that helps working > group chairs to decide when to intervene with an internal conflict > before it becomes irreversibly negative as well as being a tool that may > help determine where there is consensus on a particular topic. >=20 > We would like your help in understanding the level of conflicts within > your working groups and how the conflicts affect productivity and group > members=E2=80=99 perception on the working group. It will be greatly appr= eciated > if you could ask your WG members to anonymously fill a short survey at >=20 > https://spreadsheets.google.com/viewform?hl=3Den&formkey=3DdExTbEU5QmRncn= hFbjhQUVR4b > zBGMEE6MA >=20 > Thank you! >=20 > Best Regards, >=20 > Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From huangcb@ruijie.com.cn Wed Mar 10 00:57:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192DB3A676A for ; Wed, 10 Mar 2010 00:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieMCMziND1xk for ; Wed, 10 Mar 2010 00:57:35 -0800 (PST) Received: from mail.ruijie.com.cn (unknown [120.35.11.140]) by core3.amsl.com (Postfix) with ESMTP id 2F25D3A6765 for ; Wed, 10 Mar 2010 00:57:34 -0800 (PST) To: ospf@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: huangcb@ruijie.com.cn Message-ID: Date: Wed, 10 Mar 2010 16:57:38 +0800 X-MIMETrack: Serialize by Router on mailserver/ruijie(Release 6.5.4FP3|January 09, 2006) at 2010-03-10 16:57:41, Serialize complete at 2010-03-10 16:57:41 Content-Type: multipart/alternative; boundary="=_alternative 003126E7482576E2_=" Subject: [OSPF] Can replace the Virtual link into the Point-to-point link? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 08:57:36 -0000 This is a multipart message in MIME format. --=_alternative 003126E7482576E2_= Content-Type: text/plain; charset="US-ASCII" Hi all, In the Router-LSA, can replace the Virtual link into the Point-to-point link, and obsolete the virtual link? In RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 link in a type 1 LSA. So can I interpret it this way, the virtual link is an numbered point-to-point link and is advertised as a type 1 link in a type 1 LSA. I just want to know a separate type 4 link(Virtual link) in Router-LSA for virtual-link, what's for special applications? Thanks. --=_alternative 003126E7482576E2_= Content-Type: text/html; charset="US-ASCII"
Hi all,

  In the Router-LSA, can replace the Virtual link into the Point-to-point link, and obsolete the virtual link?
 
  In RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
  The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 link in a type 1 LSA.
 
  So can I interpret it this way, the virtual link is an numbered point-to-point link and is advertised as a type 1 link in a type 1 LSA.

  I just want to know a separate type 4 link(Virtual link) in Router-LSA for virtual-link, what's for special applications?

  Thanks.
 --=_alternative 003126E7482576E2_=-- From acee.lindem@ericsson.com Wed Mar 10 02:57:52 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADF33A68A0 for ; Wed, 10 Mar 2010 02:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+jzoEG0kx-4 for ; Wed, 10 Mar 2010 02:57:51 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A48E83A67B1 for ; Wed, 10 Mar 2010 02:57:51 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2AB0d3L027830; Wed, 10 Mar 2010 05:00:41 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 10 Mar 2010 05:57:54 -0500 From: Acee Lindem To: "" Date: Wed, 10 Mar 2010 05:57:52 -0500 Thread-Topic: [OSPF] Can replace the Virtual link into the Point-to-point link? Thread-Index: AcrAQIhl55Pf0F7DQJKnaotu/aNGUw== Message-ID: <155C5FA4-DA98-4D0C-825C-BAED6BCC0FD1@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Can replace the Virtual link into the Point-to-point link? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 10:57:52 -0000 HI Huang, The virtual link and sham link are for different purposes. The virtual link= allows one to use a transit area for backbone traffic. All the routers in = the transit area must be able to route backbone traffic. Conversely, the s= ham link is between two PEs in the same MPLS IP VPN and the traffic between= uses an MPLS LSP. None of the P routers, need to be able to route this tra= ffic. There are other differences as well but most are consequences of the = different purposes virtual links and sham links serve. Hope this helps, Acee On Mar 10, 2010, at 3:57 AM, > wrote: Hi all, In the Router-LSA, can replace the Virtual link into the Point-to-point l= ink, and obsolete the virtual link? In RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Vi= rtual Private Networks (VPNs) The sham link is an unnumbered point-to-point intra-area link and is adve= rtised as a type 1 link in a type 1 LSA. So can I interpret it this way, the virtual link is an numbered point-to-= point link and is advertised as a type 1 link in a type 1 LSA. I just want to know a separate type 4 link(Virtual link) in Router-LSA fo= r virtual-link, what's for special applications? Thanks. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From wwwrun@rfc-editor.org Wed Mar 10 11:21:13 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338C43A6A11; Wed, 10 Mar 2010 11:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkENO9FPyTe2; Wed, 10 Mar 2010 11:21:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id D938E3A6C44; Wed, 10 Mar 2010 11:18:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 55415E0740; Wed, 10 Mar 2010 11:18:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100310191841.55415E0740@rfc-editor.org> Date: Wed, 10 Mar 2010 11:18:41 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5786 on Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 19:21:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5786 Title: Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions Author: R. Aggarwal, K. Kompella Status: Standards Track Date: March 2010 Mailbox: rahul@juniper.net, kireeti@juniper.net Pages: 7 Characters: 15541 Updates: RFC3630 I-D Tag: draft-ietf-ospf-te-node-addr-07.txt URL: http://www.rfc-editor.org/rfc/rfc5786.txt OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Mar 17 11:03:45 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F473A68C6 for ; Wed, 17 Mar 2010 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9E9QngRvKGx for ; Wed, 17 Mar 2010 11:03:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id BA6AC3A6840 for ; Wed, 17 Mar 2010 11:03:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5FE7EE0743; Wed, 17 Mar 2010 11:03:54 -0700 (PDT) To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com, acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com From: RFC Errata System Message-Id: <20100317180354.5FE7EE0743@rfc-editor.org> Date: Wed, 17 Mar 2010 11:03:54 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC5340 (2078) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 18:03:45 -0000 The following errata report has been submitted for RFC5340, "OSPF for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5340&eid=2078 -------------------------------------- Type: Technical Reported by: Acee Lindem Section: 4.8.1 Original Text ------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined. Corrected Text -------------- o In Step 2, when a router Vertex V other than the root (which is the router doing the calculation) has just been added to the shortest-path tree and the router-LSA R-bit is not set in the LSA options, Vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 o Also In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit is not set in the LSA options, the transit link to W is ignored and V's next link is examined. Notes ----- This change corrects errata 2046 described below: This change reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh. Michael Barnes brought up the fact that the R-Bit should be ignored in the Router-LSA for the calculating router. This errata fixes this omission in the first paragraph of the corrected text. 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. -------------------------------------- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -------------------------------------- Title : OSPF for IPv6 Publication Date : July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Wed Mar 17 11:19:02 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0843A68B9 for ; Wed, 17 Mar 2010 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYOuOSjlfGpF for ; Wed, 17 Mar 2010 11:19:00 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 54C213A6405 for ; Wed, 17 Mar 2010 11:18:59 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2HIMC6w025590 for ; Wed, 17 Mar 2010 13:22:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 17 Mar 2010 14:19:06 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Wed, 17 Mar 2010 14:19:04 -0400 Thread-Topic: [Technical Errata Reported] RFC5340 (2078) Thread-Index: AcrF/lRwgPj7zjINTYScmVZGAESLQg== Message-ID: <204F5970-DC15-4934-B426-2C24812B4392@ericsson.com> References: <20100317180354.5FE7EE0743@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Fwd: [Technical Errata Reported] RFC5340 (2078) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 18:19:02 -0000 If you read down, you'll see this is in response to Michael Barnes' comment= that the R-Bit should be ignored in your own Router-LSA. Hopefully, this i= s the last in this area. Thanks, Acee Begin forwarded message: From: RFC Errata System > Date: March 17, 2010 2:03:54 PM EDT To: "none@rfc-editor.org" >, "dennis@juniper.net" >, "jmoy@sycamorenet.com" >, "acee@redback.com" >, "rcallon@juniper.net" >, "adrian.farrel@huawei.com" >, "acee@redback.com" >, "akr@cisco.com" > Cc: Acee Lindem >= , "ospf@ietf.org" >, "rfc-editor@rfc-editor.org" > Subject: [Technical Errata Reported] RFC5340 (2078) The following errata report has been submitted for RFC5340, "OSPF for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5340&eid=3D2078 -------------------------------------- Type: Technical Reported by: Acee Lindem Section: 4.8.1 Original Text ------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined. Corrected Text -------------- o In Step 2, when a router Vertex V other than the root (which is the router doing the calculation) has just been added to the shortest-path tree and the router-LSA R-bit is not set in the LSA options, Vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 o Also In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit is not set in the LSA options, the transit link to W is ignored and V's next link is examined. Notes ----- This change corrects errata 2046 described below: This change reflects the fact that the R-bit and the V6-bit should not be = handled identically. The R-bit allows the router to participate in the IP= v6 unicast topology but does not allow transit traffic. The V6-bit doesn't = allow either. This problem was pointed out by Balaji Ganesh. Michael Barnes brought up the fact that the R-Bit should be ignored in the = Router-LSA for the calculating router. This errata fixes this omission in t= he first paragraph of the corrected text. 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. -------------------------------------- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -------------------------------------- Title : OSPF for IPv6 Publication Date : July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Mar 18 19:19:50 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC0D3A6CD7; Thu, 18 Mar 2010 19:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJCAZHiRmUHS; Thu, 18 Mar 2010 19:19:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 877553A6CD2; Thu, 18 Mar 2010 19:19:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 38DE8E0790; Thu, 18 Mar 2010 19:19:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100319021925.38DE8E0790@rfc-editor.org> Date: Thu, 18 Mar 2010 19:19:25 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5820 on Extensions to OSPF to Support Mobile Ad Hoc Networking X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 02:19:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5820 Title: Extensions to OSPF to Support Mobile Ad Hoc Networking Author: A. Roy, Ed., M. Chandra, Ed. Status: Experimental Date: March 2010 Mailbox: akr@cisco.com, mw.chandra@gmail.com Pages: 41 Characters: 95603 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-manet-or-03.txt URL: http://www.rfc-editor.org/rfc/rfc5820.txt This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Mar 21 11:02:58 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737F13A69B2 for ; Sun, 21 Mar 2010 11:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Omu57+PIwo for ; Sun, 21 Mar 2010 11:02:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6D1223A69A6 for ; Sun, 21 Mar 2010 11:02:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0CEF9E0762; Sun, 21 Mar 2010 11:03:14 -0700 (PDT) To: rahul@juniper.net, kireeti@juniper.net, rcallon@juniper.net, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com From: RFC Errata System Message-Id: <20100321180314.0CEF9E0762@rfc-editor.org> Date: Sun, 21 Mar 2010 11:03:14 -0700 (PDT) Cc: ospf@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC5786 (2085) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:02:58 -0000 The following errata report has been submitted for RFC5786, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5786&eid=2085 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 6. Original Text ------------- IANA has assigned the Node Attribute TLV (value 5) type from the range 3-32767 as specified in [RFC3630], from the top level types in | TE LSAs registry maintained by IANA at http://www.iana.org. IANA has created and now maintains the registry for the sub-TLVs of | the Node Attribute TLV. Value 1 is reserved for Node IPv4 Local | Address sub-TLV and value 2 for Node IPv6 Local Address sub-TLV. [...] o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA | Considerations that covers the range being assigned. Corrected Text -------------- IANA has assigned the Node Attribute TLV (value 5) type from the range 3-32767 as specified in [RFC3630], from the top level types in | the TE LSAs registry maintained by IANA at http://www.iana.org. IANA has created and now maintains the registry for the sub-TLVs of | the Node Attribute TLV. Value 1 is assigned to the Node IPv4 Local | Address sub-TLV and value 2 to the Node IPv6 Local Address sub-TLV. [...] o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA | Considerations that cover the range being assigned. Notes ----- Rationale: a) missing article b) confusing use of "reserved"; IANA has _assigned_ these 2 values c) singular/plural mismatch 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. -------------------------------------- RFC5786 (draft-ietf-ospf-te-node-addr-07) -------------------------------------- Title : Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions Publication Date : March 2010 Author(s) : R. Aggarwal, K. Kompella Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From rfc-ed@rfc-editor.org Mon Mar 22 11:35:57 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D773A6952 for ; Mon, 22 Mar 2010 11:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMs5dGdW+77c for ; Mon, 22 Mar 2010 11:35:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 7555C3A684C for ; Mon, 22 Mar 2010 11:35:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id 94A72E075C; Mon, 22 Mar 2010 11:36:13 -0700 (PDT) Date: Mon, 22 Mar 2010 11:36:13 -0700 From: RFC Editor To: Alfred H?nes Message-ID: <20100322183613.GB27118@rfc-editor.org> References: <20100321180314.0CEF9E0762@rfc-editor.org> <201003211815.TAA29279@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003211815.TAA29279@TR-Sys.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ospf@ietf.org, acee@redback.com, RFC Editor , adrian.farrel@huawei.com Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:35:57 -0000 Hi Alfred, We don't determine which references should be included as normative or informative. We might make suggestions about this if someting seems odd to us, but whether references appear as normative or inforamtive is usually decided at the working group level (I believe). You may want to discuss this with the authors and working group chairs, as we are unable to provide you with any additional information about why RFC 3630 was a normative reference while RFC 5329 was listed as an informative reference. Thanks, Sandy On Sun, Mar 21, 2010 at 07:15:51PM +0100, Alfred H?nes wrote: > Hello, > as an additional remark to the Errata Note I have filed for RFC 5786 > (eid=2085): > > I do not understand why: > > - Ref. [RFC5329] is Informative and [RFC3630] is Normative > (both RFCs are mentioned in a comparable manner, e.g. in > Section 1.1 (3rd para) and Section 5), and > - the RFC only "Updates: 3630" (and not also 5329). > > Further, -- that's perhaps more a deficiency of the IANA Considerations > of RFC 5329 but could be corrected by directives to IANA -- I would > appreciate if the OSPF TE parameters registry would more clearly > indicate its applicability to OSPFv3, e.g. by giving an additional > ref. to RFC 5329 at the top level. > > > Kind regards, > Alfred H?nes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ From acee.lindem@ericsson.com Tue Mar 23 10:16:34 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DCF3A6C2D for ; Tue, 23 Mar 2010 10:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wuTiI9au0tv for ; Tue, 23 Mar 2010 10:16:33 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5EE7B3A6C18 for ; Tue, 23 Mar 2010 10:16:33 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2NHJfAC019571; Tue, 23 Mar 2010 12:19:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 23 Mar 2010 13:16:18 -0400 From: Acee Lindem To: RFC Editor , Alfred H?nes Date: Tue, 23 Mar 2010 13:16:16 -0400 Thread-Topic: [OSPF] RFC 5786 metadata, references, and IANA registry Thread-Index: AcrJ7ph69LdIMdF0Qi+cxQsupYua6gAuROrw Message-ID: References: <20100321180314.0CEF9E0762@rfc-editor.org> <201003211815.TAA29279@TR-Sys.de> <20100322183613.GB27118@rfc-editor.org> In-Reply-To: <20100322183613.GB27118@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , "adrian.farrel@huawei.com" , "acee@redback.com" Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:16:35 -0000 My take is that RFC 5329 should have stated that it updates RFC 3630. RFC 5= 728 is not dependent on RFC 5329.=20 As for the errata, I don't disagree that the suggested changes improve the = text. However, given I don't see them as warranting an errata. Afterall, we= in the IETF are an international organization and I don't see the benefit = of wordsmithing the English here. Comments such as these should be made bef= ore the RFC is published. Thanks, Acee =20 |-----Original Message----- |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 |Behalf Of RFC Editor |Sent: Monday, March 22, 2010 2:36 PM |To: Alfred H?nes |Cc: ospf@ietf.org; acee@redback.com; RFC Editor;=20 |adrian.farrel@huawei.com |Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry | |Hi Alfred, | |We don't determine which references should be included as=20 |normative or informative. We might make suggestions about=20 |this if someting seems odd to us, but whether references=20 |appear as normative or inforamtive is usually decided at the=20 |working group level (I believe). You may want to discuss this=20 |with the authors and working group chairs, as we are unable to=20 |provide you with any additional information about why RFC 3630=20 |was a normative reference while RFC 5329 was listed as an=20 |informative reference. | |Thanks, |Sandy | | |On Sun, Mar 21, 2010 at 07:15:51PM +0100, Alfred H?nes wrote: |> Hello, |> as an additional remark to the Errata Note I have filed for RFC 5786 |> (eid=3D2085): |>=20 |> I do not understand why: |>=20 |> - Ref. [RFC5329] is Informative and [RFC3630] is Normative |> (both RFCs are mentioned in a comparable manner, e.g. in |> Section 1.1 (3rd para) and Section 5), and |> - the RFC only "Updates: 3630" (and not also 5329). |>=20 |> Further, -- that's perhaps more a deficiency of the IANA=20 |> Considerations of RFC 5329 but could be corrected by directives to=20 |> IANA -- I would appreciate if the OSPF TE parameters registry would=20 |> more clearly indicate its applicability to OSPFv3, e.g. by giving an=20 |> additional ref. to RFC 5329 at the top level. |>=20 |>=20 |> Kind regards, |> Alfred H?nes. |>=20 |> -- |>=20 |>=20 |+------------------------+--------------------------------------------+ |> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math.,=20 |Dipl.-Phys. | |> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax:=20 |-18 | |> | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de =20 | | |>=20 |+------------------------+--------------------------------------------+ |_______________________________________________ |OSPF mailing list |OSPF@ietf.org |https://www.ietf.org/mailman/listinfo/ospf |= From acee.lindem@ericsson.com Wed Mar 24 08:33:09 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE4F3A6807 for ; Wed, 24 Mar 2010 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6IOdIZO1OOx for ; Wed, 24 Mar 2010 08:33:08 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 84A893A63C9 for ; Wed, 24 Mar 2010 08:33:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o2OFaimJ013968 for ; Wed, 24 Mar 2010 10:36:49 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 24 Mar 2010 11:33:23 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Wed, 24 Mar 2010 11:33:15 -0400 Thread-Topic: Updated OSPF WG Agenda Thread-Index: AcrLZ1IK08rZoMnZRM+8UDO987dEQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Updated OSPF WG Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 15:33:09 -0000 I've updated the agenda to include simplications to the OSPFv3 as a PE-CE p= rotocol draft.=20 http://www.ietf.org/proceedings/10mar/agenda/ospf.txt Also, we will need someone to take minutes and look for questions from Jabb= er.=20 Thanks, Acee= From acee.lindem@ericsson.com Wed Mar 24 15:17:45 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026F43A6810 for ; Wed, 24 Mar 2010 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnTJeYV26dj2 for ; Wed, 24 Mar 2010 15:17:36 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D85E73A69BB for ; Wed, 24 Mar 2010 15:17:29 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2OMLAnj028144; Wed, 24 Mar 2010 17:21:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 24 Mar 2010 18:17:45 -0400 From: Acee Lindem To: "ah@TR-Sys.de" Date: Wed, 24 Mar 2010 18:13:54 -0400 Thread-Topic: [OSPF] RFC 5786 metadata, references, and IANA registry Thread-Index: AcrKuZgmSQVrclvNTemyA4Qjhfay6gA4saJQ Message-ID: References: from Acee Lindem at Mar "23," 2010 "01:16:16" pm <201003231848.TAA04954@TR-Sys.de> In-Reply-To: <201003231848.TAA04954@TR-Sys.de> 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 Cc: "ospf@ietf.org" , "acee@redback.com" , "adrian.farrel@huawei.com" , "rfc-editor@rfc-editor.org" Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:17:45 -0000 Hi Alfred, =20 See inline.=20 |-----Original Message----- |From: ah@TR-Sys.de [mailto:ah@TR-Sys.de]=20 |Sent: Tuesday, March 23, 2010 2:48 PM |To: Acee Lindem |Cc: adrian.farrel@huawei.com; ospf@ietf.org;=20 |rfc-editor@rfc-editor.org; acee@redback.com |Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry | |Acee Lindem wrote: |> My take is that RFC 5329 should have stated that it updates RFC 3630. |> RFC 5728 is not dependent on RFC 5329. | |(I guess you mean RFC 5786, not RFC-to-be 5728.) | |The definition of the "Updates" metadata relation in the RFC=20 |Editor's "Instructions to RFC Authors" (instructions2authors.txt) is: | || Updates || || Specifies an earlier document whose contents are modified or || augmented by the new document. The new document cannot be || used alone, it can only be used in conjunction with the || earlier document. | |RFC 5786 applies to the OSPFv3 TE Extensions as well and as=20 |such, IMHO readers can expect the RFC metadata to point from=20 |RFC 5329 to RFC 5786 as well. I do not understand how you can=20 |implement RFC 5786 for OSPFv3 without reading/implementing RFC=20 |5329 as well. |So doesn't RFC 5786 "augment" RFC 5329 as well? |Where's the difference to the dependency on RFC 3630 for OSFPv2 ? RFC 5786 actually "updates" RFC 3630 with a new top level TE TLV. RFC 5329 = is listed a reference for those reading/implementing RFC 5786. I don't thin= k it is mandatory that it update RFC 5329 and certainly am not going to spe= nd any more time on this now that the RFC is published (at least not mine := ^).=20 | |Sometimes there are 'political' issues or hidden reasons (that=20 |better should have been explained in the memo) to not provide=20 |the expected metadata service to the readers. Since that was=20 |unclear in this case, I have asked by email. No politics here - just the editorial discretion of the authors. =20 | | |> As for the errata, I don't disagree that the suggested=20 |changes improve=20 |> the text. However, given I don't see them as warranting an errata. |> Afterall, we in the IETF are an international organization=20 |and I don't=20 |> see the benefit of wordsmithing the English here. Comments such as=20 |> these should be made before the RFC is published. |> |> Thanks, |> Acee | |Acee, |which percentage of RFCs do _you_ read before publication as well? 100% of those for which I intend to provide editorial comments.=20 Please take a look at=20 http://www.ietf.org/id/draft-ietf-ospf-af-alt-10.txt =20 Since it is on the RFC Editor queue.=20 | |I read, comment, and cross-annotate them on paper after=20 |publication (and file Errata if appropriate), and I read and=20 |comment many (sometimes long) before publication. |"RFC" still expands to "Request for Comment", and the RFC=20 |Errata process serves to channelize many of these comments for=20 |the benefit of other readers and users of the material for=20 |derived work. | |The definition of Editorial Errata at | |(or see as well) |is: | "a spelling, grammar, punctuation, or syntax error that | does not affect the technical meaning" | |Given the recent discussions on IANA terms "assigned",=20 |"allocated", "reserved", and "available for assignment" in=20 |various instances, the use of "reserved" in place of=20 |"assigned", which is the core issue addressed by Errata ID=20 |2085, arguably would even have deserved a Technical Errata=20 |Note. This does not seem to be a question of "wordsmithing"=20 |or style; it's precision in terminology. |The other details addressed in the Errata Note "en passant"=20 |are related to "grammar" / "syntax" of the language and hence=20 |the proper subject of an Editorial Erratum, per the above=20 |definition. Since all details are contained in close nearby=20 |text, I have saved errata IDs and mails and efforts in=20 |consolidating all into a single Errata Note. As I stated before, I don't disagree that your suggestions improve the text= or that "assigned" is more appropriate than "reserved". It is unfortunate = that there is not a classification of errata to categorize those which are = substantive and those that are purely editorial. Again, I'm not going to sp= end any more time debating this.=20 Thanks, Acee=20 | |Kind regards, | Alfred. | |--=20 | |+------------------------+--------------------------------------------+ || TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | || Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | || D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | |+------------------------+--------------------------------------------+ | | |> |-----Original Message----- |> |From: ospf-bounces@ietf.org On Behalf Of RFC Editor |> |To: Alfred H=CEnes |> |Cc: ospf@ietf.org; acee@redback.com; RFC Editor;=20 |> |adrian.farrel@huawei.com |> |Sent: Monday, March 22, 2010 2:36 PM |> |Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry |> | |> |Hi Alfred, |> | |> |We don't determine which references should be included as normative=20 |> |or informative. We might make suggestions about this if someting=20 |> |seems odd to us, but whether references appear as normative or=20 |> |inforamtive is usually decided at the working group level (I=20 |> |believe). You may want to discuss this with the authors=20 |and working=20 |> |group chairs, as we are unable to provide you with any additional=20 |> |information about why RFC 3630 was a normative reference while RFC=20 |> |5329 was listed as an informative reference. |> | |> |Thanks, |> |Sandy |> | |> | |> |On Sun, Mar 21, 2010 at 07:15:51PM +0100, Alfred H=CEnes wrote: |> |> Hello, |> |> as an additional remark to the Errata Note I have filed for RFC=20 |> |> 5786 |> |> (eid=3D2085): |> |> |> |> I do not understand why: |> |> |> |> - Ref. [RFC5329] is Informative and [RFC3630] is Normative |> |> (both RFCs are mentioned in a comparable manner, e.g. in |> |> Section 1.1 (3rd para) and Section 5), and |> |> - the RFC only "Updates: 3630" (and not also 5329). |> |> |> |> Further, -- that's perhaps more a deficiency of the IANA=20 |> |> Considerations of RFC 5329 but could be corrected by=20 |directives to=20 |> |> IANA -- I would appreciate if the OSPF TE parameters=20 |registry would=20 |> |> more clearly indicate its applicability to OSPFv3, e.g. by giving=20 |> |> an additional ref. to RFC 5329 at the top level. |> |> |> |> |> |> Kind regards, |> |> Alfred H=CEnes. | |= From ppsenak@cisco.com Wed Mar 31 02:06:59 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DE03A692F for ; Wed, 31 Mar 2010 02:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y66PQki6wt7f for ; Wed, 31 Mar 2010 02:06:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 2D57F3A691D for ; Wed, 31 Mar 2010 02:06:58 -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 o2V97ROf008669 for ; Wed, 31 Mar 2010 11:07:27 +0200 (CEST) Received: from dhcp-bts02-144-254-245-189.cisco.com (dhcp-bts02-144-254-245-189.cisco.com [144.254.245.189]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o2V97Pwg008600 for ; Wed, 31 Mar 2010 11:07:26 +0200 (CEST) Message-ID: <4BB310CA.8040902@cisco.com> Date: Wed, 31 Mar 2010 11:07:22 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OSPF] draft-ietf-l3vpn-ospfv3-pece-05 - ext. community X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 09:06:59 -0000 Bringing this up to the WG list to get the feedback. The discussion is about the usage of the BGP extended communities as defined for OSPFv2 versus the definition of the new one in the context of the OSPFv3 PE-CE. - draft-ietf-l3vpn-ospfv3-pece-05 defines a new OSPFv3 Route Extended Communities Attribute, which carries the exact same information as the original OSPF ext. communities defined in RFC4577. - given that most vendors that will implement draft-ietf-l3vpn-ospfv3-pece-05 have already implemented RFC4577, reusing the communities defined there would make sense. - from the operational perspective people are familiar with the original OSPF communities from the VPNv4 deployments, so they would appreciate the familiarity with those. - in the last WG meeting an argument has been used that the route-types encoding in 4.4 of draft-ietf-l3vpn-ospfv3-pece-05 does not match the one defined for OSPFv2 in 4.2.6. of RFC4577. The Route Type filed in OSPF Route Type Extended Communities Attribute as defined in RFC4577 has enough space to use the encoding as defined in draft-ietf-l3vpn-ospfv3-pece-05 and there would be no collision. An alternative is to use the route-types as defined for OSPFv2 (intra/inter/external/nssa) that match OSPFv3 route-types anyway - there is no need to carry the LSA type in this context. - draft-ietf-l3vpn-ospfv3-pece-05 uses the IPv6 Address Specific BGP Extended Community Attribute (RFC5701) that was defined specifically to carry the IPv6 address. Not sure if it's usage as a placeholder for opaque data was the intention of RFC570 as such. - other protocols are reusing the originally defined communities in IPv6 VPN context. thanks, Peter