From mkarasek@cisco.com Mon Apr 1 12:08:37 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 D6C6C11E80E6 for ; Mon, 1 Apr 2013 12:08:37 -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 PBeFEjfYnuMt for ; Mon, 1 Apr 2013 12:08:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C69E811E80E4 for ; Mon, 1 Apr 2013 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5163; q=dns/txt; s=iport; t=1364843317; x=1366052917; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WoQWAeuvRrbaQ7UEW2h8+prMQcdLEFzTIRyuxqPMntw=; b=jcDv3SvVB8aG6HkhsGvZPNlaRdQ8Vb0tvv2yuNXXlFvBwB4A52IgfiWR ovO8G+Yr/P/zgUnl2bDgHaVObhY7EnovUy+omEmeBzs3Lia905FusvYvN 14MVyrZ99zDpN2LeGnk57biPyWIfc00pzO9CNHM9B/xWfvd9uSNnjTpz6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAG++WVGtJXG+/2dsb2JhbAApGoM7v058FnSCHwEBAQQ6LRIMBAIBCBEEAQELDwIDCQcyFAkIAgQBDQUIiAwMMMAgjWSBHCYLBwYhAoI2YQOndoMLelMfPA X-IronPort-AV: E=Sophos;i="4.87,387,1363132800"; d="scan'208";a="193721486" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 01 Apr 2013 19:08:36 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r31J8alR020496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Apr 2013 19:08:36 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.206]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 14:08:35 -0500 From: "Marek Karasek (mkarasek)" To: "Bhatia, Manav (Manav)" , "vishwas.manral@hp.com" , "acee.lindem@ericsson.com" , "Stewart Bryant (stbryant)" , "adrian@olddog.co.uk" , "Abhay Roy (akr)" , "acee.lindem@ericsson.com" Thread-Topic: [Technical Errata Reported] RFC6506 (3567) Thread-Index: AQHOKuf5RpxnQnNRs0eE494S+KVBBJi/nkiAgAIXBDA= Date: Mon, 1 Apr 2013 19:08:35 +0000 Message-ID: References: <20130327123752.EFE2DB1E002@rfc-editor.org> <7C362EEF9C7896468B36C9B79200D8351BCAF79C88@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8351BCAF79C88@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.25.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) 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, 01 Apr 2013 19:08:37 -0000 Hi Manav, modularity argument is not against errata. If there's LLS implementation wh= ich does not know on TX that authentication is configured, it's perfectly O= K to compute LLS checksum. Errata says that it will not be verified on RX, = so implementations which know about authentication do not have to compute c= hecksum. I'm not saying that RFC6506 is wrong, but that it's forgotten that OSPFv3 h= as two checksums, one for standard OSPFv3 payload and second for LLS. If RF= C6506 tells how to work with checksum for the first part of the packet, it'= s useful if it also says how to work with checksum for the second part of t= he packet. For me it's natural that both parts of the packet have same hand= ling. Thanks marek -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Sunday, March 31, 2013 7:25 AM To: vishwas.manral@hp.com; acee.lindem@ericsson.com; Stewart Bryant (stbrya= nt); adrian@olddog.co.uk; Abhay Roy (akr); acee.lindem@ericsson.com Cc: Marek Karasek (mkarasek); ospf@ietf.org Subject: RE: [Technical Errata Reported] RFC6506 (3567) Hi Marek, When constructing the LLS data block it may not always be possible for an i= mplementation to know whether there is authentication being used on a link = or not. Sure there are ways for us to figure this out but it may not be a v= ery modular approach (really an implementation specific issue). If you follow rfc 6506 and do as it says then you can always choose NOT to = verify the LLS checksum upon reciept and still be compliant to 6506. This way nothing changes - Your original code for LLS still computes the ch= ecksum regardless of whether OSPFv3 AT is configured or not. The AT code co= mputes the digest of the packet including the LLS data block. The reciever verifies the AT data block and accepts the packet if it matche= s with whats carried in the packet. Its now an implementation specific issu= e whether it wants to verify the LLS checksum or not. Given this I don't think the errata raised is correct - more so, because th= is isnt really an error in the RFC.=20 Even if we'd discussed this issue when we were writing this RFC we would ha= ve left it as an implementation specific behavior at the RX side based on t= he modularity argument. Based on this argument I would also reject the errata 3568 that has been ra= ised.=20 Cheers, Manav > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Wednesday, March 27, 2013 6:08 PM > To: Bhatia, Manav (Manav); vishwas.manral@hp.com;=20 > acee.lindem@ericsson.com; stbryant@cisco.com; adrian@olddog.co.uk;=20 > akr@cisco.com; acee.lindem@ericsson.com > Cc: mkarasek@cisco.com; ospf@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC6506 (3567) >=20 > The following errata report has been submitted for RFC6506,=20 > "Supporting Authentication Trailer for OSPFv3". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6506&eid=3D3567 >=20 > -------------------------------------- > Type: Technical > Reported by: Marek Karasek >=20 > Section: 2.2 >=20 > Original Text > ------------- > Consistent with OSPFv2 Cryptographic Authentication=20 > [RFC2328], both OSPFv3 header checksum calculation and=20 > verification are omitted when the OSPFv3 authentication=20 > mechanism described in this specification is used.=20 >=20 > Corrected Text > -------------- > OSPFv3 authentication mechanism provides capability to detect=20 > corruption of OSPFv3 packet, which is under non authenticated=20 > operation achieved using OSPFv3 header checksum [RFC 5340] and LLS=20 > data block checksum [RFC 5613]. In spirit of OSPFv2 Cryptographic=20 > Authentication [RFC2328], OSPFv3 header checksum and LLS Data Block=20 > Checksum calculation and verification are omitted when the OSPFv3=20 > authentication mechanism described in this specification is used. >=20 > Notes > ----- > RFC does not specify how to work with LLS Data Block Checksum. Errata=20 > suggests omit checksum calculation/verification in the same way like=20 > for OSPFv3 header checksum. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > -------------------------------------- > Title : Supporting Authentication Trailer for OSPFv3 > Publication Date : February 2012 > Author(s) : M. Bhatia, V. Manral, A. Lindem > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From acee.lindem@ericsson.com Sun Apr 7 10:04: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 9878321F86E6 for ; Sun, 7 Apr 2013 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+dzuzT18W4K for ; Sun, 7 Apr 2013 10:04:48 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE55E21F86B2 for ; Sun, 7 Apr 2013 10:04:48 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-ff-5161a72fad83 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.5B.02430.F27A1615; Sun, 7 Apr 2013 19:04:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 13:04:47 -0400 From: Acee Lindem To: "Dolganow, Andrew (Andrew)" , "Madhukar Anand (anandmkr)" , Minto Jeyananth , "Hasmit Grover (hasmit)" , "Abhay Roy (akr)" , "ospf@ietf.org" Thread-Topic: [OSPF] Asymmetric OSPF Hold Timer draft Thread-Index: AQHOM7IBtFGBfHHCG06jCrDvmDRseA== Date: Sun, 7 Apr 2013 17:04:46 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47110224@eusaamb101.ericsson.se> In-Reply-To: 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: <6193FA7BF5D2C24B9A9309B1B52BE2D5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPlK7B8sRAg8/PeC0OH5zFZrF9+2Fm i/Uv97BYfPj7iNnidfsBZouWe/fYHdg8Wp/tZfWY8nsjq8eSJT+ZPK43XWUPYInisklJzcks Sy3St0vgyvjWwFOwyKhi86mrrA2MKzS7GDk5JARMJJ4e+swOYYtJXLi3nq2LkYtDSOAoo8TH xX9YIJxljBJvt25nAaliE9CReP7oHzNIQkRgEpNE26EzTCAJYaBRv2ZOABslImAqMR/O1pN4 378MrIZFQEWiefk9VhCbV8Bbou/LPqAaDg5OAQeJZadKQMKMQFd8P7UGrJxZQFzi1pP5TBDX CUgs2XOeGcIWlXj5+B/YGFGg8W3HzkB9oCyx5Ml+FoheHYkFuz+xgYxnFrCWeLwvAyKsLbFs 4WtmiAsEJU7OfMIygVFsFpJts5B0z0LonoWkexaS7gWMrKsYOUqLU8ty040MNjECo+6YBJvu DsY9Ly0PMUpzsCiJ8wa5XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJioVrbd6IQ4f//F COEpX57xuV2Ts5/K4hEd7z61LVdS8GuEudLUvs5NH8Pv6YVE527wnx/EUZ0p88zqKV/rByHz hwE+/k4T1Dbbv2F74xTHlXXsq+qPW/2sJqeOFt+zOnT/8J/jTjmuD47ffHz2UbJCxu+lx78+ e10b+tLrvUWYU9m5Det/MCqxFGckGmoxFxUnAgC/BOv4iAIAAA== Subject: Re: [OSPF] Asymmetric OSPF Hold Timer draft 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, 07 Apr 2013 17:04:49 -0000 We were going to relax the constraint on hello/dead timers for OSPFv3 auto-configuration. However, we were just going to remove the checking for routers supporting auto configuration rather than adding the additional encoding. In other words, auto-configured routers would simply remove the checking, ignore the hello interval, and use the neighbor's advertised dead timer. This draft could also be used for autoconfiguration although with additional complexity. Thanks, Acee On 3/22/13 1:59 AM, "Dolganow, Andrew (Andrew)" wrote: >Madhukar > >Please see inline > >On 2013-03-21 8:28 PM, "Madhukar Anand (anandmkr)" >wrote: > >>Hi Minto,=20 >> Please find our comments inline. >> >>Thanks, >>Madhukar >> >> >>On 3/21/13 11:51 AM, "Minto Jeyananth" wrote: >> >>>Madhukar,=20 >>> >>> Thanks for response. Please see inline. >>> >>>|-----Original Message----- >>>|From: Madhukar Anand (anandmkr) [mailto:anandmkr@cisco.com] >>>|Sent: Thursday, March 21, 2013 10:43 AM >>>|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr); >>>|ospf@ietf.org >>>|Subject: Re: Asymmetric OSPF Hold Timer draft >>>| >>>|Hi Minto, >>>| >>>| Thanks for your feedback and comments. Let me try to address your >>>|concerns here. >>>| >>>|Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for >>>|neighbor discover and carrying bits of information for OSPF's peers. >>> >>>Agreed OSPF HELLOs cannot be eliminated. But comment was about >>>aggressive >>>hello(/dead) interval. OSPF could be configured with high interval for >>>discovery and uses BFD for failure detection. >> >>Yes, this is true. Please note that we are not advocating one solution >>over other, which we believe is best left to the customer requirements >>and >>=20 >>Design, and not really related to any particular implementation issue. >Although you are not advocating one solution over the other, you are >proposing to add a complication to an existing protocol to do something >that can be easily achieved with longer OSPF hello timer and short BFD >timer, that can be dynamically adapted during cases like ISSU for example. >So what is the value of introducing yet another thing to solve exactly >the same problem? > >> >> >>>=20 >>>|There are use-cases (for e.g., with aggressive HELLO timers) where the >>>|recovery window may not be sufficient however efficient the >>>|implementation may be. Even with the default HELLO/dead timer, there is >>>|possibly a breaking point depending on the scale of OSPF configuration >>>|on the router. >>> >>>Again, user could configure a higher interval so that system could >>>handle >>>it. >> >> >>Yes, we agree that a BFD based approach could be used address some of the >>concerns here. Again, please note that we are not advocating one solution >>over other, which we believe is best left to the customer requirements >>and design, and not really related to any particular implementation >>issue. >> >> >>>=20 >>> >>>| >>>|Secondly, we envision that the proposed solution complements BFD. BFD >>>|could Be used for fast link down detection, and the asymmetric hold >>>|timer can be used to manage OSPF neighbor down detection. >>> >>>OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello >>>timers >>>help here to detect neighbor down but not BFD? >>> >>>| >>>|Thirdly, asymmetric hold timers have use-cases beyond the upgrade >>>|scenario highlighted here (for instance, with OSPFv3 >>>|autoconfiguration/HOMENET). >>>|We are working on adding this use-case to the draft also. >>> >>>OK. The uses cases mention in current draft seems implementation issues. >> >> >>We have other use-cases too. For instance, with the hub-and-spoke >>topology, >>It may be desirable to have different hold timers on either side. Another >>Example is with the HOMENET/OSPFv3 auto configuration where it may also >>be desirable to allow asymmetric hold timers. > >Why would you need different timers here, the only reason would be >sub-quality implementation or router deployed in a hub place that cannot >handle the deployment scale. I do not think we should be creating protocol >extensions for cases like that. > > >> >> >> >>>=20 >>> >>>Also RFC-2328 assumes hello & dead intervals are symmetric especially in >>>broadcast interfaces (wait-timer). >> >> >>This is precisely the main thrust of this proposal. We want to relax that >>assumption for a number of use-cases. To summarize, we do not believe >>this=20 >>is driven by any particular implementation need, but by the need to allow >>OSPF to function with many different customer deployments and use-cases. >> >I believe we need to have a use case that clearly demonstrates a need for >a new mechanism. Just because we can do something in a protocol, does not >mean we should do it. > >Andrew > >> >> >>> >>>-minto=20 >>> >>>| >>>|There is some discussion in Sec 4 of the draft along the lines I've >>>just >>>|highlighted. >>>|Please let us know if there are more questions. >>>| >>>|Thanks, >>>|Madhukar >>>| >>>| >>>| >>>|On 3/20/13 1:29 PM, "Minto Jeyananth" wrote: >>>| >>>|>Hi Authors, >>>|> >>>|>Expert from the draft >>>|> >>>|> "One of the implications of such busy periods of state restoration >>>|in >>>|> a process is that, the process may not be able to sustain the rate >>>|of >>>|> sending HELLOs across all its interfaces. In a controlled restart >>>|> scenario (such as OSPF Graceful restart), the router is able to ask >>>|> for a grace period by flooding out opaque LSAs indicating that it >>>is >>>|> restarting. In case of upgrades and restarts with state >>>|restoration, >>>|> (i.e., not involving a graceful restart), this is not possible." >>>|> >>>|>Does not it a pure implementation issue? Implementation could simply >>>|>prevent such an unsupported configuration. >>>|>With BFD does OSPF needs aggressive interval? >>>|> >>>|>Thanks >>>|>-minto >>>|> >>>| >> >>_______________________________________________ >>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 Sun Apr 7 11:42:18 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 2AF7321F86C9 for ; Sun, 7 Apr 2013 11:42:18 -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 JHE48q4kffpQ for ; Sun, 7 Apr 2013 11:42:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DD4CB21F8A91 for ; Sun, 7 Apr 2013 11:42:16 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-34-5161be003f17 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EC.34.02411.00EB1615; Sun, 7 Apr 2013 20:42:08 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 14:42:07 -0400 From: Acee Lindem To: OSPF List Thread-Topic: OSPF MANET Application to Single-Hop Networks Thread-Index: AQHOM7+bQCCZsuq8mU2XT6AQsdJPww== Date: Sun, 7 Apr 2013 18:42:08 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47110358@eusaamb101.ericsson.se> 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: text/plain; charset="us-ascii" Content-ID: <9F181B3AC1757F408CE115584E57B16C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXRPgi7DvsRAg8MXrCxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxok531gLulkrbq+7x9TA2MvSxcjJISFgIvFy5kJWCFtM4sK9 9WxdjFwcQgJHGSWWdk1mgnCWMUr093ewgVSxCehIPH/0jxnEFhGQlVi6ZD9Yt7CAucTf/kks EHEbiZX/WlghbD2J+S0H2EFsFgEViccvToDZvALeElPOvwSzGYE2fz+1hgnEZhYQl7j1ZD4T xEUCEkv2nGeGsEUlXj7+B3WpssT3OY9YIOp1JBbs/sQGYVtLTNr2GmqOtsSyha+ZIXYJSpyc +YRlAqPILCQrZiFpn4WkfRaS9llI2hcwsq5i5CgtTi3LTTcy3MQIDP1jEmyOOxgXfLI8xCjN waIkzhvqeiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Mzf6xF+n+HULvj+UKFNyquRR0u 7nRtWcp7UMzH+PqN9+tvvp3X0WEot3pCpeeJzDccDPVciTNdDx4IrH2kfZ7bc4nY1ylfPI6Z hma2r9RTvej5tW/GhoXb/55RvTvlUmZtnq9sWpXndPvr6b4uVaHcS3Y8s2HUShf7eyLxvnOf U1Yz++w3WUosxRmJhlrMRcWJAHPkS5lLAgAA Subject: [OSPF] OSPF MANET Application to Single-Hop 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: Sun, 07 Apr 2013 18:42:18 -0000 When we adapted RFC 6845 as a WG document, we also agree to accept the appl= ication of the OSPF MANET drafts to satisfy the one-hop requirement. In bot= h cases, there are no functional changes to the existing RFCs - only specif= ication of how the existing OSPF MANET mechanisms would be used in single-h= op networks. At this time, we believe these OSPF single-hop drafts are read= y to WG last call. While both drafts are short, they require extensive know= ledge of the OSPF MANET drafts that they update. I will asking individuals = previously involved with the OSPF MANET work to review and shepherd the dra= fts.=20 Thanks, Acee= From acee.lindem@ericsson.com Sun Apr 7 11:52: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 B403421F8867 for ; Sun, 7 Apr 2013 11:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5+Kjs2pzhaGB for ; Sun, 7 Apr 2013 11:52:49 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0721F86E6 for ; Sun, 7 Apr 2013 11:52:48 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-74-5161c0809f28 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.44.02411.080C1615; Sun, 7 Apr 2013 20:52:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 14:52:47 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt Thread-Index: AQHOM8EYrvgWOlU3J0mk3Q9C3wXCyg== Date: Sun, 7 Apr 2013 18:52:47 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4711038C@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_94A203EA12AECE4BA92D42DBFFE0AE4711038Ceusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPrG7DgcRAgyMf9C1ePetns2i5d4/d gclj1ZcJzB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp49/0Ie8Fl7ooNi/QbGP9wdjFyckgImEgc Xr+AHcIWk7hwbz1bFyMXh5DAUUaJv2enMUM4yxgldu34zwxSxSagI/H80T8wW0RAVmLpkv2s XYwcHMwC6hJ/ftqChIUFMiWufTvJAhIWEciTWHy5HKJaT2LJuyNgu1gEVCSWrpsNNoVXwFti w/5+NhCbEeiG76fWMIHYzALiEreezGeCuE1AYsme88wQtqjEy8f/WEFsUaCZbcfOQN2vLLHk yX4WiGvyJdbsN4IYLyhxcuYTlgmMIrOQTJ2FUDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjyG arWWeHA6BFnJAkaOVYwcpcWpZbnpRoabGIGxdEyCzXEH44JPlocYpTlYlMR5Q10vBAgJpCeW pGanphakFsUXleakFh9iZOLglGpgPOB+7bXcXrHJU923i8sqXUrdcE8nVHPSjLtlsxetZvFb V3615Oln/s1FIeULV7EtnsE+y8HA9dc8l5ulRotc9Uo2ZBxcfefsB17NzmW8oSdfbeFk9mCZ EmU9+W3+l7k/LhxYsf9DIVO5bmDxf4Hrxf0/vn7fnvhl+9VAo6l7ZnwyNT0uMfH9J2slluKM REMt5qLiRAABFsdDcwIAAA== Subject: [OSPF] Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-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: Sun, 07 Apr 2013 18:52:49 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4711038Ceusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'd like to start a 2 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4711038Ceusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <07C3A4E41B406E43BF4258F69EB5314A@ericsson.com> Content-Transfer-Encoding: quoted-printable 
All,=20

I'd like to start a 2 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20

https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/

Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE4711038Ceusaamb101ericsso_-- From acee.lindem@ericsson.com Sun Apr 7 11:56: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 C08BE21F8916 for ; Sun, 7 Apr 2013 11:56:30 -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=[AWL=-0.000, 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 4Rc9Oaa-orHB for ; Sun, 7 Apr 2013 11:56:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3967621F8A91 for ; Sun, 7 Apr 2013 11:56:30 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-92-5161c15d8141 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A7.54.02411.D51C1615; Sun, 7 Apr 2013 20:56: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.0318.004; Sun, 7 Apr 2013 14:56:29 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 Thread-Index: AQHOM8Gc6vHOR6/qzkik1EPe4A1EDg== Date: Sun, 7 Apr 2013 18:56:28 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE471103A7@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_94A203EA12AECE4BA92D42DBFFE0AE471103A7eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXSPn27swcRAg2vfLC3+/tzKaNFy7x67 xer3j9gdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErowrbzsZC45zVRw6foO9gfEDRxcj B4eEgInE/q6ULkZOIFNM4sK99WxdjFwcQgJHGSVeb13EDOEsY5R4t+IDC0gVm4COxPNH/5hB bBEBWYmlS/azgtjMAmESE/vPMoLYwgIlEhPfvWODqKmU+Hi1D8rWk1jZdIINZDGLgIrEmw1O IGFeAW+JrnPPwcYzAh3x/dQaJoiR4hK3nsxngjhOQGLJnvPMELaoxMvH/8DWigKNbDt2hh0i riyx5Ml+FojefIn7s5+xQswXlDg58wnLBEaRWUjGzkJSNgtJGURcR2LB7k9sELa2xLKFr5lh 7DMHHkP1WkscnLeQHVnNAkaOVYwcpcWpZbnpRoabGIHRdUyCzXEH44JPlocYpTlYlMR5Q10v BAgJpCeWpGanphakFsUXleakFh9iZOLglGpg3KSm/95UXUrZZ9+cN2kO2gcMVE+tDzSaly8W mvi+Xcv8oXah/aQWZXnGywlr5qRPX9kp+prpo00s70QG6Xmci5wk+F1UtqRbljY9nbkxjKdz Ys5H0Ys+OzLUWpauZ/22R27r67XhT0MbHs3fn+onsOtwIPvGOptQ7vmOVZIdabP+vbX9PsNT iaU4I9FQi7moOBEA7tPvo3wCAAA= Subject: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 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, 07 Apr 2013 18:56:30 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE471103A7eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'd like to start a 2 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE471103A7eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <1490887ECD3AE64CB46008F895C08295@ericsson.com> Content-Transfer-Encoding: quoted-printable 
All,=20

I'd like to start a 2 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20



Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE471103A7eusaamb101ericsso_-- From acee.lindem@ericsson.com Sun Apr 7 12:07: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 2919421F8D52 for ; Sun, 7 Apr 2013 12:07:55 -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=[AWL=-0.000, 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 9irEKyGNJ6gK for ; Sun, 7 Apr 2013 12:07:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85821F8DA4 for ; Sun, 7 Apr 2013 12:07:53 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-ec-5161c4072e03 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6C.64.02411.704C1615; Sun, 7 Apr 2013 21:07:52 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 15:07:51 -0400 From: Acee Lindem To: OSPF List Thread-Topic: 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/MQ== Date: Sun, 7 Apr 2013 19:07:50 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE471103F0@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4711038C@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_94A203EA12AECE4BA92D42DBFFE0AE471103F0eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPuC7HkcRAg813+Sxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxolf61gKrvJVHJi1hqmBcQdPFyMnh4SAiUTrhgUsELaYxIV7 69m6GLk4hASOMkoseDmJGcJZxijx5fR6JpAqNgEdieeP/jGD2CICshJLl+xnBSkSFuhglLhw +Rs7iCMi0MsoMePmPxaIKj2J5g/zGEFsFgEVicZdDUDdHBy8At4Sj3fGgIQ5BXwkZj+5BFbO CHTG91NrwJYxC4hL3HoynwniPAGJJXvOM0PYohIvH/9jBbFFgca3HTvDDhFXlljyZD8LRG++ xNs5x8F6eQUEJU7OfMIygVFkFpKxs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx1C91hKb 15xhQlazgJFjFSNHaXFqWW66keEmRmAUHZNgc9zBuOCT5SFGaQ4WJXHeUNcLAUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYVeYLtH468cVlvaH5/eunVv2zmqTDMcNkptKjUJ30BPXe3xeW q4V362vz3fl5LmTutNo9JU+tvqumXao8lzuTz3nynl6BdXWVXB2nvHjkL3uIN3a6L7OeUTjt kaRPxpaqHn4WC7MvK2rfnAm10Igv6/XZ8evkaiPlOE+W6Vf6Ql5Yc9i2yj5QYinOSDTUYi4q TgQAcNThE3ACAAA= Subject: [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: Sun, 07 Apr 2013 19:07:55 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE471103F0eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'd like to start a 3 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Thanks, Acee P.S. I meant to say 3 week WG Last Call. This is accommodate those who have= to file US taxes but haven't done so yet. --_000_94A203EA12AECE4BA92D42DBFFE0AE471103F0eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
All, 
I'd like to start a 3 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20

https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-m=
dr/

Thanks,
Acee
P.S. I meant to say 3 week WG Last Call. This is accommodate those who=
 have to file US taxes but haven't done so yet.

--_000_94A203EA12AECE4BA92D42DBFFE0AE471103F0eusaamb101ericsso_-- From acee.lindem@ericsson.com Sun Apr 7 12:10:48 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 85A1F21F8A91 for ; Sun, 7 Apr 2013 12:10:48 -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=[AWL=-0.000, 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 2nnzUBg02hxx for ; Sun, 7 Apr 2013 12:10:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DBAED21F86C1 for ; Sun, 7 Apr 2013 12:10:44 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-0a-5161c4b44038 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EA.74.02411.4B4C1615; Sun, 7 Apr 2013 21:10:44 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 15:10:43 -0400 From: Acee Lindem To: OSPF List Thread-Topic: OSPF WG Last Call: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (Corrected) Thread-Index: AQHOM8OZ3RUw9XDoHk2WrsOgeUcM9Q== Date: Sun, 7 Apr 2013 19:10:43 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4711040A@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_94A203EA12AECE4BA92D42DBFFE0AE4711040Aeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPoO6WI4mBBr93qFn8/bmV0aLl3j12 i9XvH7E7MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBnvb71nLLjIXfHxZyNTA+Mvzi5G Tg4JAROJn5suMELYYhIX7q1n62Lk4hASOMoocfXmM1YIZxmjxNy2EywgVWwCOhLPH/1jBrFF BGQlli7ZzwpiMwuESUzsPws2SVggS2LypIWMEDX5EicPLGOFsPUkbk/fB9bLIqAicePCHrCZ vALeEg0tj8DijEBXfD+1hgliprjErSfzmSCuE5BYsuc8M4QtKvHy8T+wmaJAM9uOnWGHiCtL LHmyH2gmB1BvvkRjhyTEeEGJkzOfsExgFJmFZOoshKpZSKogSnQkFuz+xAZha0ssW/iaGcY+ c+AxE4RtLTF3+jtmZDULGDlWMXKUFqeW5aYbGW5iBEbXMQk2xx2MCz5ZHmKU5mBREucNdb0Q ICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx0+T9s45+j3n/9MehoNasPw+YFzDcWZ7SsNuW 4eLcQ5ZLg9t/TP5yW3jF/uL13oUzp3fmqclX1u/6yjSxr7VvD0Od8mn7I7NfLjaq0Fk+Uebs iyn500150//6yHgKPswMl+10uTOVV77R0vasXaVLkoOAUcP6U6FsPoHm2es5mpr/bDz/x1lc iaU4I9FQi7moOBEArbJzXHwCAAA= Subject: [OSPF] OSPF WG Last Call: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (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: Sun, 07 Apr 2013 19:10:48 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4711040Aeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'd like to start a 3 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-or/ Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4711040Aeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <8FCD628F6233D94EAD078488387606BE@ericsson.com> Content-Transfer-Encoding: quoted-printable 
All,=20

I'd like to start a 3 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20

https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-or/

Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE4711040Aeusaamb101ericsso_-- From wwwrun@rfc-editor.org Tue Apr 9 19:54: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 245C221F8E9E for ; Tue, 9 Apr 2013 19:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5vQJhZDEM5Ja for ; Tue, 9 Apr 2013 19:54:47 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A121F91D4 for ; Tue, 9 Apr 2013 19:54:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5C921B1E002; Tue, 9 Apr 2013 19:54:10 -0700 (PDT) To: manav@alcatel-lucent.com, vishwas@ipinfusion.com, mfanto@aegisdatasecurity.com, riw@cisco.com, mjbarnes@cisco.com, tony.li@tony.li, rja@extremenetworks.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130410025410.5C921B1E002@rfc-editor.org> Date: Tue, 9 Apr 2013 19:54:10 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC5709 (3585) 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, 10 Apr 2013 02:54:49 -0000 The following errata report has been submitted for RFC5709, "OSPFv2 HMAC-SHA Cryptographic Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5709&eid=3585 -------------------------------------- Type: Technical Reported by: Mike Dubrovsky Section: 3.3 Original Text ------------- (1) PREPARATION OF KEY In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K), such that Ko is L octets long. Corrected Text -------------- (1) PREPARATION OF KEY In this application, Ko is always B octets long and is computed as follows: If the Authentication Key (K) is B octets long, then Ko is equal to K. If the Authentication Key (K) is more than B octets long, then Ko is set to H(K) and then appended with (B-L) zeroes to create a B octets long string Ko. If the Authentication Key (K) is less than B octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K), such that Ko is B octets long. Notes ----- This is in accordance with RFC2104(HMAC: Keyed-Hashing for Message Authentication). Reproducing the relevant text below: 2. Definition of HMAC The definition of HMAC requires a cryptographic hash function, which we denote by H, and a secret key K. We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data. We denote by B the byte-length of such blocks (B=64 for all the above mentioned examples of hash functions), and by L the byte-length of hash outputs (L=16 for MD5, L=20 for SHA-1). The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. In any case the minimal recommended length for K is L bytes (as the hash output length). See section 3 for more information on keys. Also, according to FIPS PUB 198, section 5(HMAC SPECIFICATION) : STEPS STEP-BY-STEP DESCRIPTION Step 1 If the length of K = B: set K0 = K. Go to step 4. Step 2 If the length of K > B: hash K to obtain an L byte string, then append (B-L) zeros to create a B-byte string K0 (i.e., K0 = H(K) || 00...00). Go to step 4. Step 3 If the length of K < B: append zeros to the end of K to create a B-byte string K0 (e.g., if K is 20 bytes in length and B = 64, then K will be appended with 44 zero bytes 0x00). Step 4 Exclusive-Or K0 with ipad to produce a B-byte string: K0 ¯ ipad. Step 5 Append the stream of data 'text' to the string resulting from step 4: (K0 ¯ ipad) || text. Step 6 Apply H to the stream generated in step 5: H((K0 ¯ ipad) || text). Step 7 Exclusive-Or K0 with opad: K0 ¯ opad. Step 8 Append the result from step 6 to step 7: (K0 ¯ opad) || H((K0 ¯ ipad) || text). Step 9 Apply H to the result from step 8: H((K0 ¯ opad )|| H((K0 ﾯ ipad) || text)). Step 10 Select the leftmost t bytes of the result of step 9 as the MAC. 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. -------------------------------------- RFC5709 (draft-ietf-ospf-hmac-sha-07) -------------------------------------- Title : OSPFv2 HMAC-SHA Cryptographic Authentication Publication Date : October 2009 Author(s) : M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From hannes@juniper.net Sat Apr 13 05:52: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 B03F821F848B for ; Sat, 13 Apr 2013 05:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, 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 WdpJPL0+YkZY for ; Sat, 13 Apr 2013 05:52:34 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99A21F8263 for ; Sat, 13 Apr 2013 05:52:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUWlVEcomCb6EkYiIdtDgV3X/pmVuRO5F@postini.com; Sat, 13 Apr 2013 05:52:34 PDT 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; Sat, 13 Apr 2013 05:51:40 -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; Sat, 13 Apr 2013 05:51:39 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 13 Apr 2013 05:54:02 -0700 Received: from mail188-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.23; Sat, 13 Apr 2013 12:51:38 +0000 Received: from mail188-co1 (localhost [127.0.0.1]) by mail188-co1-R.bigfish.com (Postfix) with ESMTP id 7237B120491 for ; Sat, 13 Apr 2013 12:51:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1155h) Received: from mail188-co1 (localhost.localdomain [127.0.0.1]) by mail188-co1 (MessageSwitch) id 1365857496223263_16642; Sat, 13 Apr 2013 12:51:36 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.242]) by mail188-co1.bigfish.com (Postfix) with ESMTP id 34636240060; Sat, 13 Apr 2013 12:51:36 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 13 Apr 2013 12:51:35 +0000 Received: from [172.23.3.159] (66.129.224.53) by pod51010.outlook.com (10.255.243.34) with Microsoft SMTP Server (TLS) id 14.16.293.5; Sat, 13 Apr 2013 12:51:33 +0000 Message-ID: <516954D0.6010605@juniper.net> Date: Sat, 13 Apr 2013 14:51:28 +0200 From: Hannes Gredler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VERIZON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LEVEL3.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-FOPE-CONNECTOR: Id%12219$Dn%AMAZON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Tom Scholl , Shane Amante , "Jalil, Luay" Subject: [OSPF] draft-gredler-ospf-label-advertisement 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, 13 Apr 2013 12:52:34 -0000 dear ospf-wg, in orlando i have presented in RTGWG and MPLSWG use-cases for IGP advertisment of MPLS labels. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement here is the draft outlining the actual protocol extensions for OSPF http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement the authors would love to hear feedback, opinions, flames ;-) thanks, /hannes From acee.lindem@ericsson.com Tue Apr 16 06:25: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 7608F21F95EC for ; Tue, 16 Apr 2013 06:25: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 EcEuKzmsWF2J for ; Tue, 16 Apr 2013 06:25:40 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C972521F85D9 for ; Tue, 16 Apr 2013 06:25:39 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-48-516d5152d67e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FB.C8.02411.3515D615; Tue, 16 Apr 2013 15:25:39 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 09:25:38 -0400 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-02.txt Thread-Index: AQHOOeOSDbUAghYTzE6S7gRB0UqTt5jYpbGA Date: Tue, 16 Apr 2013 13:25:37 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47119364@eusaamb101.ericsson.se> In-Reply-To: <20130415141431.15135.2984.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.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E4A3241C9BD4642A7AC892037C0F73A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXSPt25wYG6gQft6SYuWe/fYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TfxP2PBWeGKqR8bWBoYH/F3MXJySAiYSJx8+44JwhaTuHBv PVsXIxeHkMBRRomNmx6xQzjLGSXO//gJVsUmoCPx/NE/ZhBbREBWYumS/awgtrBAiMS7JZ1s EPFQiavnzrNC2EYSx+ZtA7NZBFQlpiy6BzaHV8Bb4s/7b2BzOAUcJR53bWYBsRmBrvh+ag1Y DbOAuMStJ/OhrhOQWLLnPDOELSrx8vE/sJmiAnoSbcfOsEPElSW+z3nEAtGrI7Fg9yc2CNta 4vjxS4wQtrbEsoWvmSFuEJQ4OfMJywRGsVlI1s1C0j4LSfssJO2zkLQvYGRdxchRWpxalptu ZLiJERgrxyTYHHcwLvhkeYhRmoNFSZw31PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG dL8bz5lWbdX8nPqrcG2+7XNGQffbqfaSonuU+P5e2h9pe+sNv/LFmAjzvf8nv3n27RPLq36V cimVCjX2ip22HGJc/z9/ZTNSkXw8cdpS8aZaHtaazfdtb89fLFP/Ns/QXFzN4mpnY77WHN6m NfFPT1+bW/rJ57Gbf3GN0rSQjgfyFUtaFosrsRRnJBpqMRcVJwIA/k8V8WMCAAA= Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:25:40 -0000 This version includes a change to allow differing hello/dead intervals for auto-configured routers. This was based on input in the Homenet WG and interoperability testing between auto-configured implementations. 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]. I also put MANET requirements out of scope. Auto-configured operation over wireless networks requiring a point-to-multipoint (P2MP) topology and dynamic metrics based on wireless feedback is not within the scope of this document. However, auto-configuration is not precluded in these environments. Thanks, Acee On 4/15/13 7:14 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-ospf-ospfv3-autoconfig-02.txt >has been successfully submitted by Acee Lindem and posted to the >IETF repository. > >Filename: draft-ietf-ospf-ospfv3-autoconfig >Revision: 02 >Title: OSPFv3 Auto-Configuration >Creation date: 2013-04-15 >Group: ospf >Number of pages: 17 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-autoconfig-02.t >xt >Status: =20 >http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-autoconfig-02 > >Abstract: > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be self-configuring. > > =20 > =20 > > >The IETF Secretariat > From wwwrun@rfc-editor.org Wed Apr 17 03:20: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 2734121F8E48 for ; Wed, 17 Apr 2013 03:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, 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 MCEhv0g0qX9Q for ; Wed, 17 Apr 2013 03:20:17 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4D21F86E4 for ; Wed, 17 Apr 2013 03:20:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EBCB1B1E002; Wed, 17 Apr 2013 03:19:16 -0700 (PDT) To: sina@nuovasystems.com, ppsenak@cisco.com, acee@redback.com, aoswal@redback.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130417101916.EBCB1B1E002@rfc-editor.org> Date: Wed, 17 Apr 2013 03:19:16 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC5185 (3595) 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, 17 Apr 2013 10:20:19 -0000 The following errata report has been submitted for RFC5185, "OSPF Multi-Area Adjacency". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5185&eid=3595 -------------------------------------- Type: Technical Reported by: Marek Karasek Section: 4 Original Text ------------- A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The neighbor's IPv6 link local address can be learned in other ways, e.g., it can be extracted from the IPv6 header of Hello packets received over the multi-area adjacency. The neighbor IPv6 link local address is required for the OSPFv3 route next-hop calculation on multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]). Corrected Text -------------- OSPFv3 supports two Address Families (AF), AF IPv6 and AF IPv4, using separate instances [RFC 5338]. The route calculation differs for the IPv4 and IPv6 address families with respect to the next-hop determination. OSPFv3 instances supporting an IPv6 AF SHOULD learn the IPv6 next-hop address from the IPv6 Header source address and SHOULD NOT advertise a Link-LSA for a multi-area adjacency. However, for OSPFv3 instances supporting an IPv4 AF, the next-hop address cannot be learned from the OSPFv3 hellos and require advertisement of the Link-LSA. Hence, OSPFv3 instances supporting an IPv4 AF SHOULD advertise a Link-LSA for the a multi-area adjacency (refer to section 2.5 of [RFC 5838]). If the Link-LSA is not advertised, the OSPFv3 instance MAY learn the IPv4 next-hop address from the Link-LSA advertised on the primary adjacency. Notes ----- RFC5185 describes next-hop calculation which is not applicable to OSPFv3 process supporting AF IPv4 as defined in RFC5838. Errata defines how RFC5838 OSPFv3 process supporting AF IPv4 calculates next-hop address on multi-area interface. 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. -------------------------------------- RFC5185 (draft-ietf-ospf-multi-area-adj-09) -------------------------------------- Title : OSPF Multi-Area Adjacency Publication Date : May 2008 Author(s) : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From johnsonhammond1@hushmail.com Sat Apr 27 14:07: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 9B4FB21F994C for ; Sat, 27 Apr 2013 14:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 YcWj7ePxXfCK for ; Sat, 27 Apr 2013 14:07:03 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 2396A21F9944 for ; Sat, 27 Apr 2013 14:07:02 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 7EBC41B531D for ; Sat, 27 Apr 2013 17:31:41 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:31:41 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 4FDBDE673F; Sat, 27 Apr 2013 17:31:41 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:31:41 -0400 To: ospf@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173141.4FDBDE673F@smtp.hushmail.com> Subject: [OSPF] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 21:07:03 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.