From service@gmx.co.uk Fri Oct 3 04:08:30 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BB93A67CC for ; Fri, 3 Oct 2008 04:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.015 X-Spam-Level: *** X-Spam-Status: No, score=3.015 tagged_above=-999 required=5 tests=[BAYES_60=1, LOTTERY_PH_004470=2.015] 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 BwYZmNcvOwmC for ; Fri, 3 Oct 2008 04:08:27 -0700 (PDT) Received: from mail.roldansia.com.co (mail.roldanlogistica.com.co [200.14.236.118]) by core3.amsl.com (Postfix) with SMTP id 96B123A6778 for ; Fri, 3 Oct 2008 04:08:25 -0700 (PDT) Received: (qmail 10190 invoked from network); 3 Oct 2008 10:20:43 -0000 Received: from unknown (HELO www.roldansia.com.co) (127.0.0.1) by localhost with SMTP; 3 Oct 2008 10:20:43 -0000 Received: from 196.220.2.122 (proxying for 192.168.1.27) (SquirrelMail authenticated user ecordoba@roldansia.com.co) by www.roldansia.com.co with HTTP; Fri, 3 Oct 2008 05:20:43 -0500 (COT) Message-ID: <53236.196.220.2.122.1223029243.squirrel@www.roldansia.com.co> Date: Fri, 3 Oct 2008 05:20:43 -0500 (COT) Subject: Reference Number: BMW:2551256003/23 From: "INTERNATIONAL AWARENESS PROMOTIONS" Reply-To: mr_richard_gray@hotmail.co.uk User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal To: undisclosed-recipients:; Reference Number: BMW:2551256003/23 INTERNATIONAL AWARENESS PROMOTION DEPARTMENT OF THE BMW AUTOMOBILE COMPANY in collaboration with eBay. 508, King's Road, Chelsea, London. Congratulations! You are the STAR PRIZE WINNER of this year! The Board of Directors, members of staff and the International Awareness Promotion Department of the BMW Automobile Company in collaboration with eBay, wishes to congratulate you on your success as the STAR PRIZE WINNER of this year's BMW Automobile International Awareness Promotion (IAP) held today in Madrid, Spain. This makes you the proud owner of a brand new BMW 5 Series 550i Sport Saloon car and a cash prize of £45,000.00 (FOURTY FIVE THOUSAND POUNDS STERLINGS ONLY) To collect your prize please contact our Claims Manager Richard Gray. Please include the following information in your email: 1.Full Name: 2.Full Address (the address where the prize will be received) 3.Status: 4.Occupation: 5.Age: 6.Sex: 7.Country: 8.Tel.Number Mr. Richard Gray eBay's BMW Claims Department EMAIL: mr_richard_gray@hotmail.co.uk Phone: +44 70319 94608 +44 7031 90 7562. Regards, MR. DANIEL SMITH DIRECTOR OF PROMOTIONS, INTERNATIONAL AWARENESS PROMOTIONS, BMW AUTOMOBILE in colaboration with eBay. From ospf-bounces@ietf.org Mon Oct 6 02:08:47 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884CE3A6A6A; Mon, 6 Oct 2008 02:08:47 -0700 (PDT) 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 AC47F3A6A6B for ; Mon, 6 Oct 2008 02:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.736 X-Spam-Level: * X-Spam-Status: No, score=1.736 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 UiFoLgex31kW for ; Mon, 6 Oct 2008 02:08:45 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7737E3A6A5E for ; Mon, 6 Oct 2008 02:08:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B007WE835MH@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 17:09:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B00IER835BP@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 17:09:05 +0800 (CST) Received: from rajeshsm ([10.18.23.152]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8B0074B83371@szxml04-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 17:09:05 +0800 (CST) Date: Mon, 06 Oct 2008 14:39:03 +0530 From: Rajesh Shetty To: ospf@ietf.org Message-id: <002201c92793$2e4f8950$9817120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [OSPF] NSSA RFC 3101 Section 2.5 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: , Content-Type: multipart/mixed; boundary="===============0687240534==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0687240534== Content-type: multipart/alternative; boundary="Boundary_(ID_02s2eVAkLXZVRQ1dfhoEQw)" This is a multi-part message in MIME format. --Boundary_(ID_02s2eVAkLXZVRQ1dfhoEQw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, Section 2.5 (Calculating Type-7 AS External Routes) of RFC 3101 (NSSA) refers to section 16.4.1 of Base RFC. Below red marked statement in section 16.4.1 does not hold good for NSSA. Section 16.4.1: " When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11" In NSSA when trying to decide which of several AS-external-LSAs (In case of type5, type7 LSAs) should be preferred, paths might terminate at same or different ASBRs/forwarding address. So I think for clarity its better to mention section 16.4.1 in NSSA RFC with required changes. Correct me if I am missing any information. Thanks Rajesh 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! --Boundary_(ID_02s2eVAkLXZVRQ1dfhoEQw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi All,
 

Section 2.5 (Calculating Type-7 AS External Routes) of RFC 3101 (NSSA) refers to section 16.4.1 of Base RFC. Below red marked statement in section 16.4.1 does not hold good for NSSA.

 

Section 16.4.1:

 

" When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11"

 

 

In NSSA when trying to decide which of several AS-external-LSAs (In case of type5, type7 LSAs) should be preferred, paths might terminate at same or different ASBRs/forwarding address.

 

So I think for clarity its better to mention section 16.4.1 in NSSA RFC with required changes.

Correct me if I am missing any information.

 

Thanks

Rajesh

 

 

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!
--Boundary_(ID_02s2eVAkLXZVRQ1dfhoEQw)-- --===============0687240534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0687240534==-- From ospf-bounces@ietf.org Mon Oct 6 03:10:20 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D719828B56A; Mon, 6 Oct 2008 03:10:20 -0700 (PDT) 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 AF2D93A6A22 for ; Mon, 6 Oct 2008 03:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.828 X-Spam-Level: * X-Spam-Status: No, score=1.828 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 gHZ9+AKfoS3s for ; Mon, 6 Oct 2008 03:10:18 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 51E9B3A689D for ; Mon, 6 Oct 2008 03:10:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B007SHAXVMH@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 18:10:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B006YGAXVMB@szxga03-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 18:10:43 +0800 (CST) Received: from rajeshsm ([10.18.23.152]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8B0004XAXUN8@szxml04-in.huawei.com> for ospf@ietf.org; Mon, 06 Oct 2008 18:10:43 +0800 (CST) Date: Mon, 06 Oct 2008 15:40:42 +0530 From: Rajesh Shetty To: ospf@ietf.org Message-id: <001001c9279b$cac28690$9817120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [OSPF] NSSA - Setting E bit in Router LSA 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: , Content-Type: multipart/mixed; boundary="===============0665763466==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0665763466== Content-type: multipart/alternative; boundary="Boundary_(ID_x7n0UfoJmkeI6lDs1u8jjw)" This is a multi-part message in MIME format. --Boundary_(ID_x7n0UfoJmkeI6lDs1u8jjw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, As per NSSA RFC 3101, setting E bit in Router LSA: ALL NSSA border routers set bit E in those router-LSAs originated into directly attached Type-5 capable areas. An NSSA's AS boundary routers also set bit E in their router-LSAs originated into the NSSA. Since NSSA border routers does not set E bit in router LSA which its originate for NSSA area, when internal routers in NSSA area does route calculation for Default Type-7 As-external LSA (Generated by NSSA border routers for inter-as reachability) ASBR cannot be found in originating NSSA. This will prevent internal routers from installing Default route there by preventing inter-as reachability. I think NSSA border routers should set Ebit in those router-LSAs originated into directly attached Type-5 capable areas as well as to directly attached NSSA areas (When import summaries is set to enabled). Correct me if I am missing any information. Thanks Rajesh 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! --Boundary_(ID_x7n0UfoJmkeI6lDs1u8jjw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi=20 All,

 

As=20 per NSSA RFC 3101, setting E bit in Router LSA:

ALL=20 NSSA border routers set bit E in those router-LSAs originated into = directly=20 attached Type-5 capable areas.=20 An NSSA=92s AS boundary routers also set bit E in their router-LSAs = originated=20 into the NSSA.

 

Since=20 NSSA border routers does not set E bit in router LSA which its originate = for=20 NSSA area, when internal routers in NSSA area does route calculation for = Default=20 Type-7 As-external LSA (Generated by NSSA border routers for inter-as=20 reachability) ASBR cannot be found in originating NSSA. This will = prevent=20 internal routers from installing Default route there by preventing = inter-as=20 reachability.

 

I=20 think NSSA border routers should set Ebit in those router-LSAs originated into directly attached = Type-5 capable=20 areas as well as to directly attached NSSA areas (When import summaries = is set=20 to enabled).

 

Correct=20 me if I am missing any information.

 

Thanks

Rajesh

 

 

This e-mail and attachments contain = confidential=20 information from HUAWEI, which is intended only for the person or entity = whose=20 address is listed above. Any use of the information contained herein in = any way=20 (including, but not limited to, total or partial disclosure, = reproduction, or=20 dissemination) by persons other than the intended recipient's) is = prohibited. If=20 you receive this e-mail in error, please notify the sender by phone or = email=20 immediately and delete it!
--Boundary_(ID_x7n0UfoJmkeI6lDs1u8jjw)-- --===============0665763466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0665763466==-- From franck.stephanie5@orange.fr Mon Oct 6 06:25:51 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A513A67D8 for ; Mon, 6 Oct 2008 06:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.691 X-Spam-Level: X-Spam-Status: No, score=-23.691 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 Oy4b-g0O8L-q for ; Mon, 6 Oct 2008 06:25:49 -0700 (PDT) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.47]) by core3.amsl.com (Postfix) with ESMTP id 450803A68FB for ; Mon, 6 Oct 2008 06:25:48 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2111.orange.fr (SMTP Server) with ESMTP id 339091C00096 for ; Mon, 6 Oct 2008 15:26:24 +0200 (CEST) Received: from ACaen-157-1-100-208.w90-17.abo.wanadoo.fr (ACaen-157-1-100-208.w90-17.abo.wanadoo.fr [90.17.35.208]) by mwinf2111.orange.fr (SMTP Server) with SMTP id 5FF5D1C000AF for ; Mon, 6 Oct 2008 15:26:23 +0200 (CEST) X-ME-UUID: 20081006132623393.5FF5D1C000AF@mwinf2111.orange.fr Received: from [90.17.35.208] (port=24811 helo=ACaen-157-1-100-208.w90-17.abo.wanadoo.fr) by lists.ietf.org with esmtp id 331da1-d4ae6c-1d for ospf-archive@lists.ietf.org; Mon, 06 Oct 2008 15:30:18 +0100 Message-ID: <48EA12EA.8010404@lists.ietf.org> Date: Mon, 06 Oct 2008 15:30:18 +0100 From: "Gale" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Colette" Subject: High-quality service is guaranteed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit D'u want to have perfect sex all night long?
Buy and take and ms
Save your money buy ms here.
Boost your power now!

http://ilntts.roledbintel.net/?88530310

Instant worldwide shipping and friendly support
From ospf-bounces@ietf.org Mon Oct 6 06:51:23 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFE83A6AC9; Mon, 6 Oct 2008 06:51:23 -0700 (PDT) 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 5298E3A6ACD for ; Mon, 6 Oct 2008 06:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 7cQW8631NYHv for ; Mon, 6 Oct 2008 06:51:16 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 656FB3A68BA for ; Mon, 6 Oct 2008 06:51:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,367,1220220000"; d="scan'208";a="17709035" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2008 15:51:50 +0200 Message-ID: <48EA17F5.9040209@inria.fr> Date: Mon, 06 Oct 2008 15:51:49 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ospf@ietf.org References: <20080922070001.5E5893A6953@core3.amsl.com> In-Reply-To: Subject: Re: [OSPF] WG Last Call for draft-ietf-ospf-manet-or-01.txt 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Abhay, a couple of editorial comments on draft-ietf-ospf-manet-or-01: - Section 3.5 on Smart Peering is still "sticking out" a bit too much, i.e. it still shows that it was a separate draft at some point. I thus suggest renaming the subsections 3.5.1 up to 3.5.3 so that it does not mention "Introduction", "Previous Related Work" or "Proposed Solution", but rather mention directly bits of Smart Peering specification. - Section 3.5.4. should be renamed to "Advertizing 2-Way Links in Router LSAs". Cheers, Emmanuel Abhay Roy a =E9crit : > As we decided in Philadelphia, we are starting Last Call of > MANET drafts. First one is this revision of the subject draft. > = > All OSPF MANET drafts are intended to be Experimental > status. The OSPF WG last call will begin today and will end > at 12:00 AM EDT, October 6, 2008. > = > -Abhay/Acee > = > On 09/22/08-0700 at 12:00am, Internet-Drafts@ietf.org writes: > = >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Open Shortest Path First IGP Working >> Group of the IETF. >> >> >> Title : Extensions to OSPF to Support Mobile Ad Hoc >> Networking >> Author(s) : M. Chandra, A. Roy >> Filename : draft-ietf-ospf-manet-or-01.txt >> Pages : 34 >> Date : 2008-09-21 >> >> This document describes extensions to OSPF to support mobile ad hoc >> networking. Specifically, the document specifies a mechanism for >> link-local signaling, a 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. >> >> Chandra, Roy et al. >> >> >> >> Expires March 2009 >> >> >> >> [page 1] >> >> Internet-Draft >> Extensions to OSPF to Support MANETs >> September 2008 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-or-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > _______________________________________________ > 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 ospf-bounces@ietf.org Mon Oct 6 07:24:56 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B2B3A6A6D; Mon, 6 Oct 2008 07:24:56 -0700 (PDT) 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 6FD2B3A6ABC for ; Mon, 6 Oct 2008 07:24:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U98ri54EKnDN for ; Mon, 6 Oct 2008 07:24:54 -0700 (PDT) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id B034B3A6A6D for ; Mon, 6 Oct 2008 07:24:51 -0700 (PDT) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N0EB9RWBPC00D38F@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon, 06 Oct 2008 07:25:22 -0700 (PDT) Date: Mon, 06 Oct 2008 07:25:21 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01N0EB9RWBPE00D38F@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,rajeshsm@huawei.com MIME-version: 1.0 Cc: RAJESHSM@HUAWEI.COM Subject: Re: [OSPF] NSSA RFC 3101 Section 2.5 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Rajesh, >These rules apply when the same ASBR is reachable through multiple areas, >or when trying to decide which of several AS-external-LSAs should be >preferred. In the former case the paths all terminate at the same ASBR, >while in the latter the paths terminate at separate ASBRs/forwarding >addresses. >In NSSA when trying to decide which of several AS-external-LSAs (In >case of type5, type7 LSAs) should be preferred, paths might terminate >at same or different ASBRs/forwarding address. I am not sure what you are saying here. 16.4.1 certainly applies on NSSA border routers where both Type 7 and Type 5 LSAs might exist for the same prefix. They have equal status as AS external LSAs when 16.4.1 is applied. Keep in mind that a type-7 LSA MUST be originated with a forwarding address from its NSSA as defined in RFC 3101 2.4. Hence an NSSA border router MUST choose different forwarding addresses when advertising the same prefix into two different NSSAs. Also, Type-5 LSAs must pick their forwarding addresses from non-NSSA areas, the only exception being Type 7 LSA translation. Furthermore if two NSSA ASBRs originate functionally equivalent Type-7 LSAs (i.e., same destination, cost and non-zero forwarding address), one of them flushes its LSA, also as defined in Section 2.4. Realizing this where is the conflict? Note that I purposely referenced 16.4.1 without change so that RFC 3101 would not require change at a later date should 16.4.1 change. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Oct 6 07:53:35 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9816F3A6A69; Mon, 6 Oct 2008 07:53:35 -0700 (PDT) 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 484BD3A6A69 for ; Mon, 6 Oct 2008 07:53:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBPOQqc2kc9V for ; Mon, 6 Oct 2008 07:53:28 -0700 (PDT) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id E611D3A6A4A for ; Mon, 6 Oct 2008 07:53:28 -0700 (PDT) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N0ECACLFGC00D38F@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon, 06 Oct 2008 07:54:04 -0700 (PDT) Date: Mon, 06 Oct 2008 07:54:04 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01N0ECACLFGE00D38F@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,rajeshsm@huawei.com MIME-version: 1.0 Cc: RAJESHSM@HUAWEI.COM Subject: Re: [OSPF] NSSA - Setting E bit in Router LSA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Rajesh, >As per NSSA RFC 3101, setting E bit in Router LSA: >ALL NSSA border routers set bit E in those router-LSAs >originated into directly attached Type-5 capable areas. An >NSSA's AS boundary routers also set bit E in their router-LSAs >originated into the NSSA. >Since NSSA border routers does not set E bit in router LSA which >its originate for NSSA area, when internal routers in NSSA area >does route calculation for Default Type-7 As-external LSA >(Generated by NSSA border routers for inter-as reachability) >ASBR cannot be found in originating NSSA. This will prevent >internal routers from installing Default route there by >preventing inter-as reachability. >I think NSSA border routers should set Ebit in those router-LSAs >originated into directly attached Type-5 capable areas as well >as to directly attached NSSA areas (When import summaries is >set to enabled). >From RFC 3101, ...Like OSPF ASBRs, an NSSA router indicates it is an NSSA ASBR by setting the E-bit in its router-LSA. I believe RFC 3101 makes no exception to this statement. Hence even an NSSA border router that originates any Type-7 LSA (including the Type 7 default LSA) MUST set the E-bit in its router-LSA as it is also an ASBR. However if an NSSA border router does not originate any Type 7 LSAs into an NSSA (even in RFC 1587 when importing summary LSAs the origination of a Type 7 default LSA was optional) then it may optionally not set the E-bit in its router-LSA for that NSSA. I don't see a problem with this. Summary routes are not Type 7 LSAs and, when installed, are preferred over Type 7 LSA paths. One might do this if they want default traffic to follow an NSSA originated Type 7 default LSA possibly for security reasons. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Oct 6 09:15:36 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC22E28C0DC; Mon, 6 Oct 2008 09:15:36 -0700 (PDT) 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 341FD3A67FC for ; Mon, 6 Oct 2008 09:15:36 -0700 (PDT) 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 1IvrYHYtdZ30 for ; Mon, 6 Oct 2008 09:15:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 725CA28C0DC for ; Mon, 6 Oct 2008 09:15:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,368,1220227200"; d="scan'208";a="169695896" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2008 16:15:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m96GFqeO018063; Mon, 6 Oct 2008 09:15:52 -0700 Received: from [10.21.149.44] (sjc-vpn7-1324.cisco.com [10.21.149.44]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m96GFpFj004357; Mon, 6 Oct 2008 16:15:52 GMT Message-ID: <48EA39B7.8030408@cisco.com> Date: Mon, 06 Oct 2008 09:15:51 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Emmanuel Baccelli References: <20080922070001.5E5893A6953@core3.amsl.com> <48EA17F5.9040209@inria.fr> In-Reply-To: <48EA17F5.9040209@inria.fr> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2832; t=1223309752; x=1224173752; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20[OSPF]=20WG=20Last=20Call=20for=20draft -ietf-ospf-manet-or-01.txt |Sender:=20; bh=Qecza3zViN8/N353PVZP5UAZNc0DzqwOkVuUWC24rsk=; b=iL4QENe+qOia2M82MyLstOch2+J8AX9nOIcxG/mrDHjF2dk3LvQh6oZhFM 23NORbCASfLyWEYnD8rAoYXiq1oCgtwpuX/14PrRjec08bT8e0R7WmisSLO4 +/e5/qhJT9; Authentication-Results: sj-dkim-3; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ospf@ietf.org Subject: Re: [OSPF] WG Last Call for draft-ietf-ospf-manet-or-01.txt 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Thanks Emmanuel. We will rename them.. Regards, -Abhay On 10/6/2008 6:51 AM, Emmanuel Baccelli wrote: > Hi Abhay, > = > a couple of editorial comments on draft-ietf-ospf-manet-or-01: > = > - Section 3.5 on Smart Peering is still "sticking out" a bit too much, > i.e. it still shows that it was a separate draft at some point. I thus > suggest renaming the subsections 3.5.1 up to 3.5.3 so that it does not > mention "Introduction", "Previous Related Work" or "Proposed Solution", > but rather mention directly bits of Smart Peering specification. > = > - Section 3.5.4. should be renamed to "Advertizing 2-Way Links in Router > LSAs". > = > Cheers, > Emmanuel > = > = > = > = > Abhay Roy a =E9crit : >> As we decided in Philadelphia, we are starting Last Call of >> MANET drafts. First one is this revision of the subject draft. >> >> All OSPF MANET drafts are intended to be Experimental >> status. The OSPF WG last call will begin today and will end >> at 12:00 AM EDT, October 6, 2008. >> >> -Abhay/Acee >> >> On 09/22/08-0700 at 12:00am, Internet-Drafts@ietf.org writes: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Open Shortest Path First IGP Working >>> Group of the IETF. >>> >>> >>> Title : Extensions to OSPF to Support Mobile Ad Hoc >>> Networking >>> Author(s) : M. Chandra, A. Roy >>> Filename : draft-ietf-ospf-manet-or-01.txt >>> Pages : 34 >>> Date : 2008-09-21 >>> >>> This document describes extensions to OSPF to support mobile ad hoc >>> networking. Specifically, the document specifies a mechanism for >>> link-local signaling, a 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. >>> >>> Chandra, Roy et al. >>> >>> >>> >>> Expires March 2009 >>> >>> >>> >>> [page 1] >>> >>> Internet-Draft >>> Extensions to OSPF to Support MANETs >>> September 2008 >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-or-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Oct 6 09:19:00 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8043C3A6ADA; Mon, 6 Oct 2008 09:19:00 -0700 (PDT) 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 9605E3A6AD2 for ; Mon, 6 Oct 2008 09:18:59 -0700 (PDT) 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 dmqsscY4nYIC for ; Mon, 6 Oct 2008 09:18:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9B4FE3A6A27 for ; Mon, 6 Oct 2008 09:18:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,368,1220227200"; d="scan'208";a="92609558" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2008 16:19:35 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m96GJY6O026471 for ; Mon, 6 Oct 2008 09:19:34 -0700 Received: from [10.21.149.44] (sjc-vpn7-1324.cisco.com [10.21.149.44]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m96GJXpc003833 for ; Mon, 6 Oct 2008 16:19:33 GMT Message-ID: <48EA3A95.3060302@cisco.com> Date: Mon, 06 Oct 2008 09:19:33 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: OSPF List References: <20080922070001.5E5893A6953@core3.amsl.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2041; t=1223309974; x=1224173974; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20[OSPF]=20WG=20Last=20Call=20complete=20 for=20draft-ietf-ospf-manet-or-01.txt |Sender:=20; bh=UloiufWbYN5vVyU2EnXVFAWCdKMfo4KJkT1JPm2tGlQ=; b=fGpw0+vTqtbEyXDqkwZkDu1NQvLav4WgTZTH+H4bMlePfaaQKXWwHmcTL6 MutDwKeTu3hYMM1PA9t3gHFmQoAs7iTGQA0As0TxbBg0LUGycdpx/Az5xP5/ Rg4WJZm94e; Authentication-Results: sj-dkim-3; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [OSPF] WG Last Call complete for draft-ietf-ospf-manet-or-01.txt 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, Last call completed without any further issues. We will take the I-D to the IESG. -Abhay/Acee On 9/22/2008 12:16 AM, Abhay Roy wrote: > As we decided in Philadelphia, we are starting Last Call of > MANET drafts. First one is this revision of the subject draft. > > All OSPF MANET drafts are intended to be Experimental > status. The OSPF WG last call will begin today and will end > at 12:00 AM EDT, October 6, 2008. > > -Abhay/Acee > > On 09/22/08-0700 at 12:00am, Internet-Drafts@ietf.org writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Open Shortest Path First IGP Working >> Group of the IETF. >> >> >> Title : Extensions to OSPF to Support Mobile Ad Hoc >> Networking >> Author(s) : M. Chandra, A. Roy >> Filename : draft-ietf-ospf-manet-or-01.txt >> Pages : 34 >> Date : 2008-09-21 >> >> This document describes extensions to OSPF to support mobile ad hoc >> networking. Specifically, the document specifies a mechanism for >> link-local signaling, a 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. >> >> Chandra, Roy et al. >> >> >> >> Expires March 2009 >> >> >> >> [page 1] >> >> Internet-Draft >> Extensions to OSPF to Support MANETs >> September 2008 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-or-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > _______________________________________________ > 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 ospf-bounces@ietf.org Mon Oct 6 09:20:42 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE6E3A6970; Mon, 6 Oct 2008 09:20:42 -0700 (PDT) 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 CEE4C3A6970 for ; Mon, 6 Oct 2008 09:20:41 -0700 (PDT) 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 V8NZxEWZ5-nF for ; Mon, 6 Oct 2008 09:20:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0A99B3A67B4 for ; Mon, 6 Oct 2008 09:20:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,368,1220227200"; d="scan'208";a="47883448" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2008 16:21:17 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m96GLHo6015554 for ; Mon, 6 Oct 2008 09:21:17 -0700 Received: from [10.21.149.44] (sjc-vpn7-1324.cisco.com [10.21.149.44]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m96GLHS3005842 for ; Mon, 6 Oct 2008 16:21:17 GMT Message-ID: <48EA3AFD.7040009@cisco.com> Date: Mon, 06 Oct 2008 09:21:17 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: OSPF List DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2502; t=1223310077; x=1224174077; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20WG=20Last=20Call=20for=20draft-ietf-ospf-manet- mdr-02.txt |Sender:=20; bh=rWD8Nn/VlpAZdtNwVNDxDgpw/p0z86RABKR7JX8kK4Y=; b=vJ4mLr0Q5LM8z3aNd7gwCssY3FJpE+srHHZGLz1dipPIUcBwNJh8qqJf14 5QJuPdGJBFArpOtM/9Oraj8H/GHgDK0SPk6f/HxjqWc4PuSK5lWOns5AFUAy V8VcgXrGaMfPxX9eNKC8TirTvuhrFbYIODOfUnAI1v1vIE4f3y790=; Authentication-Results: sj-dkim-1; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [OSPF] WG Last Call for draft-ietf-ospf-manet-mdr-02.txt 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org We are starting WG Last Call of this revision of the subject draft. This drafts is intended to be Experimental status. The OSPF WG last call will begin today and will end at 12:00 AM EDT, October 20, 2008. Abhay/Acee -------- Original Message -------- Subject: I-D Action:draft-ietf-ospf-manet-mdr-02.txt Date: Tue, 10 Jun 2008 21:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : MANET Extension of OSPF using CDS Flooding Author(s) : R. Ogier, et al. Filename : draft-ietf-ospf-manet-mdr-02.txt Pages : 62 Date : 2008-06-10 This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 9 01:06:11 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA643A6C79; Thu, 9 Oct 2008 01:06:11 -0700 (PDT) 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 69F053A6C79 for ; Thu, 9 Oct 2008 01:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 rx4rPwXM4tN6 for ; Thu, 9 Oct 2008 01:06:09 -0700 (PDT) Received: from web8404.mail.in.yahoo.com (web8404.mail.in.yahoo.com [202.43.219.152]) by core3.amsl.com (Postfix) with SMTP id 2FB913A6A21 for ; Thu, 9 Oct 2008 01:06:08 -0700 (PDT) Received: (qmail 71517 invoked by uid 60001); 9 Oct 2008 08:06:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=tytx4LV6LTqALVoxh0RNSzHVQpODrrv7Gk/AXWBEF+wIVXBRp0SLe9v0dep0AR9tI8PByi5KFuJVCkW0tQmdufE6Cwf5c3IAXaVnCSy7vQfk+oqzgV9z0jkLAVqwL230BxCn5uvdM1f4fuj5mfPj3Cj28n6ee4txHLtYmaS/CHQ=; X-YMail-OSG: W6JSy9sVM1mGDSorCUsuNhYJk1YTs9He8bd0kWmZl8iJV6Kg4729vSUuckWyvYPkKyfrld0K.9A2zD1M6CBhfrLqFTO1dSjZRAJIHG1x9N_18UWUVO15zcXRGFOXcxW6lyE09OhXPOkwB_V3NhNrJGgQNn0u2rAFY5x.lOxu.YJkg_l0lK0- Received: from [210.94.41.89] by web8404.mail.in.yahoo.com via HTTP; Thu, 09 Oct 2008 13:36:39 IST X-Mailer: YahooMailWebService/0.7.218.2 Date: Thu, 9 Oct 2008 13:36:39 +0530 (IST) From: Pranjal Chakravarty To: ospf@ietf.org MIME-Version: 1.0 Message-ID: <968449.71446.qm@web8404.mail.in.yahoo.com> Subject: [OSPF] is N1 Route preffered over E1 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pranjalchakravarty@yahoo.co.in List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068516402==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0068516402== Content-Type: multipart/alternative; boundary="0-1799043622-1223539599=:71446" --0-1799043622-1223539599=:71446 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Suppose a Router recive the info abt a external Route by a E1 Route and ano= ther by a N1 Route .Will ECMP will happen and two routes will be installed = on the router or a single route will be preffered .We know that E1 route is= always preffered over E2 Route .My question is does N1 route is preffered = over E1 Route or vice versa?=0A=0A=0A Add more friends to your messeng= er and enjoy! Go to http://messenger.yahoo.com/invite/ --0-1799043622-1223539599=:71446 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Invite them now. --0-1799043622-1223539599=:71446-- --===============0068516402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0068516402==-- From ospf-bounces@ietf.org Thu Oct 9 06:38:09 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F15E3A6A92; Thu, 9 Oct 2008 06:38:09 -0700 (PDT) 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 392203A6A92 for ; Thu, 9 Oct 2008 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=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 v0ExsQYvFeXs for ; Thu, 9 Oct 2008 06:38:07 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 4E2B03A685F for ; Thu, 9 Oct 2008 06:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 899D75A9E5E; Thu, 9 Oct 2008 06:38:51 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32424-06; Thu, 9 Oct 2008 06:38:51 -0700 (PDT) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 5834D5A9E5C; Thu, 9 Oct 2008 06:38:51 -0700 (PDT) In-Reply-To: <968449.71446.qm@web8404.mail.in.yahoo.com> References: <968449.71446.qm@web8404.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <2F8772B4-7F81-40C2-83D5-6696757ADDCA@redback.com> From: Acee Lindem Date: Thu, 9 Oct 2008 09:38:50 -0400 To: pranjalchakravarty@yahoo.co.in X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] is N1 Route preffered over E1 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: , Content-Type: multipart/mixed; boundary="===============0395757961==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0395757961== Content-Type: multipart/alternative; boundary=Apple-Mail-1-439194799 --Apple-Mail-1-439194799 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 9, 2008, at 4:06 AM, Pranjal Chakravarty wrote: > Suppose a Router recive the info abt a external Route by a E1 Route > and another by a N1 Route .Will ECMP will happen and two routes > will be installed on the router or a single route will be > preffered .We know that E1 route is always preffered over E2 > Route .My question is does N1 route is preffered over E1 Route or > vice versa? I assume by N1 you're referring to IOS's "show ip route" type for an NSSA type 1 route. RFC 3101 will prefer the E1 or N1 route based on the following rules from section 2.5: (d) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, select the preferred path based on a least cost comparison. Type 1 external paths are compared by looking at the sum of the distance to the ASBR/forwarding addresses and the advertised type 1 metric (X+Y). Type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the ASBR/forwarding addresses. ~[OSPF] (e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. However, if the E1 route and the N1 route are, in fact, equal-cost then usually this is a moot point since they both use the same forwarding address. Hope this helps, Acee > > Add more friends to your messenger and enjoy! Invite them now. > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-1-439194799 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Oct 9, 2008, = at 4:06 AM, Pranjal Chakravarty wrote:

Suppose a Router recive the info abt = a external Route by a E1 Route and another by a N1 Route .Will ECMP will = happen and two routes will be installed on the router or a single route = will be preffered .We know that E1 route is always preffered over E2 = Route .My question is does N1 route is preffered over E1 Route or vice = versa?

<= div>I assume by N1 you're referring to IOS's "show ip route" type for an = NSSA type 1 route. RFC 3101 will prefer the E1 or N1 route based on the = following rules from section 2.5:=A0

=A0=A0 = =A0 =A0 =A0 =A0(d) If the new AS external path is still = indistinguishable
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0from the = current paths in N's routing table entry, select
=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0the preferred path based on a least cost comparison. = =A0Type
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A01 external paths are = compared by looking at the sum of the
=A0=A0 =A0 =A0 =A0 =A0 =A0= =A0distance to the ASBR/forwarding addresses and the
=A0=A0 =A0= =A0 =A0 =A0 =A0 =A0advertised type 1 metric (X+Y). =A0Type 2 external = paths
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0advertising equal type 2 = metrics are compared by looking
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0at= the distance to the ASBR/forwarding addresses.
=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0~[OSPF]

=A0=A0 =A0 =A0 =A0 =A0(e) = If the current LSA is functionally the same as an
=A0=A0 =A0 =A0= =A0 =A0 =A0 =A0installed LSA (i.e., same destination, cost and = non-zero
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0forwarding address) = then apply the following priorities in
=A0=A0 =A0 =A0 =A0 =A0 = =A0 =A0deciding which LSA is preferred:

=A0=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. A Type-7 LSA with the P-bit = set.

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. A = Type-5 LSA.

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 3. The LSA with the higher router = ID.


However, if the E1 = route and the N1 route are, in fact, equal-cost then usually this is a = moot point since they both use the same forwarding = address.=A0
Hope this = helps,
Acee



Add more friends to your = messenger and enjoy! Invite them now.
OSPF mailing list

= --Apple-Mail-1-439194799-- --===============0395757961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0395757961==-- From ospf-bounces@ietf.org Thu Oct 9 11:42:51 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586933A69F6; Thu, 9 Oct 2008 11:42:51 -0700 (PDT) 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 6A64B3A69F6 for ; Thu, 9 Oct 2008 11:42:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTkKekTYYfbj for ; Thu, 9 Oct 2008 11:42:49 -0700 (PDT) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id A49CF3A69B8 for ; Thu, 9 Oct 2008 11:42:49 -0700 (PDT) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01N0IR512DF400D3TQ@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Thu, 09 Oct 2008 11:42:50 -0700 (PDT) Date: Thu, 09 Oct 2008 11:42:50 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: ACEE@REDBACK.COM Message-id: <01N0IR512ECY00D3TQ@omega7.wr.usgs.gov> X-VMS-To: acee@redback.com X-VMS-Cc: ospf@ietf.org,pranjalchakravarty@yahoo.co.in MIME-version: 1.0 Cc: OSPF@IETF.ORG, PRANJALCHAKRAVARTY@YAHOO.CO.IN Subject: Re: [OSPF] is N1 Route preffered over E1 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee, Regarding your answer to > Suppose a Router recive the info abt a external Route by a E1 Route > and another by a N1 Route .Will ECMP will happen and two routes > will be installed on the router or a single route will be > preffered .We know that E1 route is always preffered over E2 > Route .My question is does N1 route is preffered over E1 Route or > vice versa? don't forget the pruning defined in OSPF RFC 2328 16.4.1. There o Intra-area paths using non-backbone areas are always the most preferred. For the purpose of the AS External route calculation defined in RFC 3101 an E1 Type 5 LSA has no inherent preference over an N1 Type 7 LSA. Hence an N1 Type 7 LSA path over its non-backbone NSSA will prune an E1 Type 5 LSA path over the transit topology regardless of the metric. Of course this only applies when RFC1583Compatibility is set to "disabled". This pruning happens in Step 3 (for 0.0.0.0 fwd addrs only) and again in Step 6(c), which is before the metric comparison in Step 6(d). Now regarding equal-cost E1 and N1 routes with the same non-zero forwarding address, a proper Type 5/7 LSA calculation will have long since pruned the E1 Type 5 LSA path based on the following text in Step 3. If the forwarding address is non-zero look up the forwarding address in the routing table. For a Type-5 LSA the matching routing table entry must specify an intra-area or inter-area path through a Type-5 capable area. For a Type-7 LSA the matching routing table entry must specify an intra-area path through the LSA's originating NSSA. If no such path exists then do nothing with this LSA and consider the next in the list. Note that the only time an E1 Type 5 LSA and an N1 Type 7 LSA should have the same non-zero forwarding address is during Type 7 LSA translation. This paragraph should cause the E1 Type 5 LSA to be skipped. When originating other Type 5 LSAs the forwarding address should never be picked from a stub area or an NSSA except during translation. To do so can cause routing loops and dropped packets. Of course Type 7 LSAs always have forwarding addresses from the NSAA. Note it is hard to envision where Step 6(e) plays much of a role during a steady state NSSA topology. It might play a more significant role when the NSSA topology loosely splits. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From jabbar.abdalsaml0@gmail.com Thu Oct 9 15:53:48 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230923A679F for ; Thu, 9 Oct 2008 15:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MX=0.535] 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 U-hX+3yb5OEb for ; Thu, 9 Oct 2008 15:53:47 -0700 (PDT) Received: from aluxe.matcuer.unam.mx (aluxe.matcuer.unam.mx [132.248.41.2]) by core3.amsl.com (Postfix) with ESMTP id E811D3A6868 for ; Thu, 9 Oct 2008 15:53:46 -0700 (PDT) Received: from matcuer.unam.mx (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by aluxe.matcuer.unam.mx (8.14.2/8.14.2) with ESMTP id m99MQNad020759; Thu, 9 Oct 2008 17:26:30 -0500 From: "Mr.Jabbar Qadim" Reply-To: jabbar.abdalsami0@gmail.com Subject: HELLO. Date: Thu, 9 Oct 2008 17:26:23 -0500 Message-Id: <20081009222425.M34407@matcuer.unam.mx> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 77.246.64.242 (mario) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-matcuer-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m99MQNad020759 X-matcuer-MailScanner: Found to be clean X-matcuer-MailScanner-From: jabbar.abdalsaml0@gmail.com To: undisclosed-recipients:; My Dear Beloved How are you doing? hope fine. I am very sorry to contact you like this, my nameis Mr.Jabbar Qadim, from Yemen, i have a very severe Oesophageal cancer that the doctors said will lead to death in few Months time after trying all medical treatment. I have given most of my assets to my family members and i have decided to give the other part to charity organisations. I cannot do this myself anymore because of my health. I once asked members of my family to give some money to charity organizations,they refused and kept the money.I have Eighteen Million Dollars with a security company abroad and i want you to help me collect the 18Million Dollars and use it for charity works.I will also like to know if you can travel out of your country for this transaction since it will be better for you to meet up with the officials of the company.Better still you can advise me on what to do in other for this transaction to be successful.Let's join our head together and make this come successful.Am not strong to follow you up on this. You will take out 20% of this funds for your assistance. If you are willing to assist me, do contact me as soon possible. Regards, Mr.Jabbar Qadim -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ospf-bounces@ietf.org Mon Oct 13 10:56:20 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745593A6AC4; Mon, 13 Oct 2008 10:56:20 -0700 (PDT) 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 50E6C28C167 for ; Mon, 13 Oct 2008 10:56:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7dZtJN4DnmP for ; Mon, 13 Oct 2008 10:56:18 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 91FD63A68AA for ; Mon, 13 Oct 2008 10:56:18 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8O00DXXV69N9@usaga01-in.huawei.com> for OSPF@IETF.ORG; Mon, 13 Oct 2008 10:56:33 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8O00C0QV68IK@usaga01-in.huawei.com> for OSPF@IETF.ORG; Mon, 13 Oct 2008 10:56:33 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [122.167.135.73]) by szxmc03-in.huawei.com (mshttpd); Mon, 13 Oct 2008 22:56:14 +0500 Date: Mon, 13 Oct 2008 22:56:14 +0500 From: RajeshShettyM 70520 To: OSPF@IETF.ORG Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal Subject: [OSPF] OSPFv3 TE Topology 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi All, In OSPFv3 TE RFC we depend upon Local Interface IPv6 Address, Remote Interface IPv6 Address to build TE topology (This is not a good mechanism to build TE topology in IPV6 since an interface might have many ipv6 addresses). Way this TE topology is formed is not inline with OSPFv3 base RFC where we focus on network-protocol-independent topology. My suggestion is we can come up with a new Interface ID sub-TLV for the link TLV. Which specifies the Interface ID assigned to the interface being described.Using this Sub-TLV and Neighbor ID Sub-TLV we can form a network-protocol-independent TE topology. Correct me if i am missing any information Thanks Rajesh ****************************************************************************************** This email and its 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 here 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 email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Oct 20 00:04:29 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5397E3A68FF; Mon, 20 Oct 2008 00:04:29 -0700 (PDT) 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 049AB3A68FF for ; Mon, 20 Oct 2008 00:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35] 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 EWNQ2OgVgGkY for ; Mon, 20 Oct 2008 00:04:26 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 439C03A698E for ; Mon, 20 Oct 2008 00:04:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,449,1220220000"; d="scan'208";a="18936671" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2008 09:05:35 +0200 Message-ID: <48FC2DBB.1000502@inria.fr> Date: Mon, 20 Oct 2008 09:05:31 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ospf@ietf.org References: <48EA3AFD.7040009@cisco.com> In-Reply-To: <48EA3AFD.7040009@cisco.com> X-Enigmail-Version: 0.95.7 Subject: Re: [OSPF] WG Last Call for draft-ietf-ospf-manet-mdr-02.txt 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, here are some comments I had about draft-ietf-ospf-manet-mdr-02. Section 1.1. (Terminology) ..."MDR Other A router is an MDR Other for a particular MANET interface if it is neither an MDR nor a Backup MDR for that interface." # Comment 1. It is not clear enough whether this is per interface or not. By transitivity, it is not clear enough if being MDR is by interface or not. If it is, add a line such as "this is per interface". If not add a line such as "this is per node", for this definition and the definition of MDR. ..."Bidirectional Neighbor A neighboring router whose neighbor state is 2-Way or greater. The set of such neighbors is called the Bidirectional Neighbor Set (BNS)." # Comment 2. same as above. It is no clear enough whether this is per interface or not. If it is, add a line such as "this is per interface". If not add a line such as "this is per node". ..."Non-flooding MDR An MDR that does not immediately flood received LSAs back out the receiving interface. Some MDRs may declare themselves non- flooding in order to reduce flooding overhead. # Comment 3. Suggestion: make this a positive definition that says what a non-flooding MDR does (instead of saying what it does not do, which is less precise). So say something like: "a non-flooding MDR is an MDR that delays its flood". ..."Backup Parent If the option of biconnected adjacencies is chosen, then each MDR Other selects a Backup Parent..." # Comment 4. Reading the document, it is not clear enough if the "option of biconnected adjacencies" is identical with Adjconnectivity=3D2 or not. If it is the same, then there should be just one denomination throughout the draft. If it is not, then the draft should contain some text about the difference between the two. ..."Backup MANET Designated Router (Backup MDR or BMDR) One of a set of routers responsible for providing backup flooding when neighboring MDRs fail." # Comment 5. Are BMDRs useful if Adjconnectivity is not 2? Reading the draft it is not obvious. It should be clearer in the specification what is the tie between such options? Section 2.2. (Flooding Procedure) ..."When an MDR receives a new LSA on a MANET interface, it immediately floods the LSA back out the receiving interface unless it can be determined that such flooding is unnecessary." # Comment 6. In case of multiple MANET interfaces, this text may be confusing. What about transmissions on other interface? My suggestion is to add some text here about operation in such case. And some text should also be added to precise if MDRs are per interface or not (ref Comment 1). Section 2.5. (Partial and Full Topology LSAs) # Comment 7. It seems that LSAFullness =3D 2 does not exist? In this case, it would be more coherent to just use LSAFullness=3D0,1,2,3 instead of 0,1,3,4. # Comment 8. Reading the specification, it is not clear enough whether heterogeneous LSAFullness is supported or not. What is the compatibility of different routers using different LSAFullness in the same network? For example if one router uses LSAFullness 0 and all the other routers use LSAFullness 4, do we still get the properties of LSAFullness 4 (Shortest Paths etc.)? I guess not, so there should be some text precising that all the routers must use the same LSAFullness and/or some text that characterizes more precisely the properties resulting in various LSAFullnesses present in the network. # Comment 9. The text characterizing the properties of LSAFullness =3D 0 should include the mention that with this setting, actual path cost may systematically differ from the computed path cost, which may cause concerns if traffic engineering is of importance. Section 3.2. (New Configurable Interface Parameters) # Comment 10. Is heterogeneous Adjconnectivity is supported? What is the compatibility of different routers using different Adjconnectivity? Some text should clearly specify this. # Comment 11. What is the compatibility of different Adjconnectivity settings with repsect to different LSAFullness settings? Some text should clearly specify this too. Section 4.2.3. (Additional Processing for Both Hello Types) "If the router itself belongs to the neighbor's DNS" # Comment 12. I assume this is a typo: change "DNS" into "BNS". Section 5. (MDR Selection Algorithm) # Comment 13. Some text should indicate that bi-connectivity of MDR and BMDR is available only if the network is itself bi-connected. Section 5.1. (Phase 1: Creating the Neighbor Connectivity Matrix) # Comment 14. There should be a clear indication whether the connectivity Matrix is ()i per interface or (ii) per node. Section 5.4. (Phase 4: Selection of the (Backup) Parent) # Comment 15. The step sequence in this section is not specified. There should be a clear sequence of steps that is assured to provide no contradictions between subsequent actions. Section 6.1. (Interface States) # Comment 16. Does every node in the network need to have the same 2HopRefresh? Or does it work also with various settings in the network? This is not clear enough in the specification. There should be some text about this. Section 8. (Flooding Procedure) # Comment 17. The introduction of the term "covered" neighbor should be in terminology. Section 8 should just specify flooding procedure, and be more concise, for clarity purposes. Recommendation: rewrite a more consise specification. Section 8.1 (LSA Forwarding Procedure) ..."(5) If the router is a flooding MDR for this interface," # Comment 18. This brings apparent contradictions with section 2.2. Is MDR per interface? Per node? What happens in case of multiple MANET interfaces? Some text should specify this in the draft. # Comment 19. Transition between step 5 and step 6 is confusing. Step 5 floods the LSAs, and step 6 seems to "undo" some transmissions done in step 5? Should step 5 come in fact after step 6? # Comment 20. Covered optimization (used in steps 2, 4 and 6) is very complex, and not straightforward to implement since it is much more than "last-hop" dependent flooding: it is "multiple neighbor's last hop" dependent flooding. Is this mechanism really necessary, since there is already a CDS? Section 8.1.1 (Note on Step 6 of LSA Forwarding Procedure) # Comment 21. This should not be in the specification. Maybe this should be in a "BCP" document instead? Section B.2. (Detailed Algorithm for Step 3.2 (BMDR Selection)) # Comment 22. There is an optional algorithm for BMDR computation (b) which seems to not be recommended. So why not remove it altogether? Comment 23. General comment: the specification should be more consistent with the denomination of the different options. Comment 24. General comment: there many options. - 4 levels of LSAFullness - 3 levels of AdjConnectivity - 2HopRefresh value (various differential Hellos) - non-flooding MDR option It would be very useful and clearer to have a table somewhere in appendix that summarizes all the possible configurations of option settings and which indicates which configurations are functional and which are not. Best regards, Emmanuel Abhay Roy a =E9crit : > = > We are starting WG Last Call of this revision of the subject draft. > = > This drafts is intended to be Experimental status. The OSPF WG last call > will begin today and will end at 12:00 AM EDT, October 20, 2008. > = > Abhay/Acee > = > -------- Original Message -------- > Subject: I-D Action:draft-ietf-ospf-manet-mdr-02.txt > Date: Tue, 10 Jun 2008 21:45:03 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ospf@ietf.org > = > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Open Shortest Path First IGP Working > Group of the IETF. > = > = > Title : MANET Extension of OSPF using CDS Flooding > Author(s) : R. Ogier, et al. > Filename : draft-ietf-ospf-manet-mdr-02.txt > Pages : 62 > Date : 2008-06-10 > = > This document specifies an extension of OSPF for IPv6 to support > mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is > designed as a new OSPF interface type for MANETs. OSPF-MDR is based > on the selection of a subset of MANET routers, consisting of MANET > Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected > dominating set (CDS), and the MDRs and Backup MDRs together form a > biconnected CDS for robustness. This CDS is exploited in two ways. > First, to reduce flooding overhead, an optimized flooding procedure > is used in which only (Backup) MDRs flood new link state > advertisements (LSAs) back out the receiving interface; reliable > flooding is ensured by retransmitting LSAs along adjacencies. > Second, adjacencies are formed only between (Backup) MDRs and a > subset of their neighbors, allowing for much better scaling in dense > networks. The CDS is constructed using 2-hop neighbor information > provided in a Hello protocol extension. The Hello protocol is > further optimized by allowing differential Hellos that report only > changes in neighbor states. Options are specified for originating > router-LSAs that provide full or partial topology information, > allowing overhead to be reduced by advertising less topology > information. > = > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-02.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 ospf-bounces@ietf.org Tue Oct 21 07:49:33 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF823A6A99; Tue, 21 Oct 2008 07:49:33 -0700 (PDT) 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 E311B3A6AA6 for ; Tue, 21 Oct 2008 07:49:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSStKpnPVs0j for ; Tue, 21 Oct 2008 07:49:30 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id C7F5C3A6A70 for ; Tue, 21 Oct 2008 07:49:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Dcr8KJ1zX2uXHukUwmFtcBg9Zlc+r51/+eicDY/0zV6tgxEGh0xWFIkZ9IAqr9kD; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.220.217] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KsIZA-0006aH-3G; Tue, 21 Oct 2008 10:50:44 -0400 Message-ID: <48FDFAC2.6090101@earthlink.net> Date: Tue, 21 Oct 2008 07:52:34 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel Baccelli References: <48EA3AFD.7040009@cisco.com> <48FC2DBB.1000502@inria.fr> In-Reply-To: <48FC2DBB.1000502@inria.fr> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478757195e1c3cf0a9243c0f9abe367690d710a5f772637642c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.220.217 Cc: ospf@ietf.org Subject: Re: [OSPF] WG Last Call for draft-ietf-ospf-manet-mdr-02.txt 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Emmanuel, Thanks for your comments. Please see my responses below. I plan to submit an updated draft soon. Emmanuel Baccelli wrote: >Hi, > >here are some comments I had about draft-ietf-ospf-manet-mdr-02. > > > >Section 1.1. (Terminology) > > >..."MDR Other > A router is an MDR Other for a particular MANET interface if it is > neither an MDR nor a Backup MDR for that interface." > ># Comment 1. It is not clear enough whether this is per interface or >not. By transitivity, it is not clear enough if being MDR is by >interface or not. If it is, add a line such as "this is per interface". >If not add a line such as "this is per node", for this definition and >the definition of MDR. I think the phrase "for a particular MANET interface" implies that it is per interface. However, I will also clarify this for the definition of an MDR. Also, note that MDR Level and Parent are interface variables. This is similar to OSPF, which selects a DR for each broadcast interface. > >..."Bidirectional Neighbor > A neighboring router whose neighbor state is 2-Way or greater. > The set of such neighbors is called the Bidirectional Neighbor Set > (BNS)." > ># Comment 2. same as above. It is no clear enough whether this is per >interface or not. If it is, add a line such as "this is per interface". >If not add a line such as "this is per node". I will clarify that the BNS is defined for each interface. > > >..."Non-flooding MDR > An MDR that does not immediately flood received LSAs back out the > receiving interface. Some MDRs may declare themselves non- > flooding in order to reduce flooding overhead. > ># Comment 3. Suggestion: make this a positive definition that says what >a non-flooding MDR does (instead of saying what it does not do, which is >less precise). So say something like: "a non-flooding MDR is an MDR that >delays its flood". OK, I can add that a non-flooding MDR performs backup flooding like a BMDR (as specified in later sections). >..."Backup Parent > If the option of biconnected adjacencies is chosen, then each MDR > Other selects a Backup Parent..." > ># Comment 4. Reading the document, it is not clear enough if the "option >of biconnected adjacencies" is identical with Adjconnectivity=3D2 or not. >If it is the same, then there should be just one denomination throughout >the draft. If it is not, then the draft should contain some text about >the difference between the two. AdjConnectivity is a parameter, and "biconnected adjacencies" describes what it means for AdjConnectivity to equal 2. The equivalence of these two is indicated in Section 3.2 where AdjConnectivity is defined. In graph theory, a graph is "biconnected" if its connectivity is 2, so this is the same thing. > >..."Backup MANET Designated Router (Backup MDR or BMDR) > One of a set of routers responsible for providing backup flooding > when neighboring MDRs fail." > ># Comment 5. Are BMDRs useful if Adjconnectivity is not 2? Reading the >draft it is not obvious. It should be clearer in the specification what >is the tie between such options? This is made clear in the last two sentences of page 23: "Also, Phase 3 (BMDR selection) is not required if AdjConnectivity is 0 or 1. However, Phase 3 MUST be executed if AdjConnectivity is 2, and SHOULD be executed if AdjConnectivity is 0 or 1, since BMDRs improve robustness by providing backup flooding." > >Section 2.2. (Flooding Procedure) > >..."When an MDR receives a new LSA on a MANET interface, it immediately > floods the LSA back out the receiving interface unless it can be > determined that such flooding is unnecessary." > ># Comment 6. In case of multiple MANET interfaces, this text may be >confusing. What about transmissions on other interface? My suggestion is >to add some text here about operation in such case. And some text should >also be added to precise if MDRs are per interface or not (ref Comment 1). Section 2.2 just gives a brief, informal overview of the operation. The detailed operation for flooding is given in Section 8, including the case of multiple interfaces. > >Section 2.5. (Partial and Full Topology LSAs) > ># Comment 7. It seems that LSAFullness =3D 2 does not exist? In this case, > it would be more coherent to just use LSAFullness=3D0,1,2,3 instead of >0,1,3,4. LSAFullness =3D 2 does exist, but its exact implementation is left to the implementer. It is defined by the last paragraph on page 41, by requiring the set of advertised neighbors to be a superset of the set corresponding to LSAFullness =3D 1. The idea is to allow the router to advertise additional neighbors to provide redundant routes. Note that an exact algorithm need not be specified, since it is not necessary for different routers to use the same algorithm, as noted in the last paragraph of Section 9.3. ># Comment 8. Reading the specification, it is not clear enough whether >heterogeneous LSAFullness is supported or not. What is the compatibility >of different routers using different LSAFullness in the same network? >For example if one router uses LSAFullness 0 and all the other routers >use LSAFullness 4, do we still get the properties of LSAFullness 4 >(Shortest Paths etc.)? I guess not, so there should be some text >precising that all the routers must use the same LSAFullness and/or some >text that characterizes more precisely the properties resulting in >various LSAFullnesses present in the network. The fact that different routers can use different values of the new interface parameters (including LSAFullness and AdjConnectivity) is made clear in the following paragraph of Section 3.2: "Although all routers should preferably choose the same values for the new configurable interface parameters, this is not required. OSPF- MDR was carefully designed so that correct interoperation is achieved even if each router sets these parameters independently of the other routers." It is stated that LSAFullness =3D 1 or 4 provides shortest paths, and that LSAFullness =3D 0 does not. As you concluded, shortest paths are not guaranteed even if only one router uses LSAFullness =3D 0. To clarify this, I will add the following: Routing along shortest paths is provided if and only if LSAFullness is 1, 2, or 4 for every router. ># Comment 9. The text characterizing the properties of LSAFullness =3D 0 >should include the mention that with this setting, actual path cost may >systematically differ from the computed path cost, which may cause >concerns if traffic engineering is of importance. Actual path cost can only be better than the computed path cost, since each router may have knowledge of first-hop links that are not advertised in router-LSAs. I don't think this will cause any problem. However, I will mention this fact in the document since it may be useful to know this. >Section 3.2. (New Configurable Interface Parameters) > ># Comment 10. Is heterogeneous Adjconnectivity is supported? What is the >compatibility of different routers using different Adjconnectivity? Some >text should clearly specify this. > ># Comment 11. What is the compatibility of different Adjconnectivity >settings with repsect to different LSAFullness settings? Some text >should clearly specify this too. As I mentioned above, the fact that different routers can use different values of the new interface parameters (including LSAFullness and AdjConnectivity) is made clear in the paragraph from Section 3.2 that I quoted above. This is an attractive feature of OSPF-MDR as has been discussed on the list (e.g., see the post of Matthew Thomas on 12/7/2007). > >Section 4.2.3. (Additional Processing for Both Hello Types) > > > > "If the router itself belongs to the neighbor's DNS" > ># Comment 12. I assume this is a typo: change "DNS" into "BNS". "DNS" (Dependent Neighbor Set) is correct. > >Section 5. (MDR Selection Algorithm) > ># Comment 13. Some text should indicate that bi-connectivity of MDR and >BMDR is available only if the network is itself bi-connected. OK, I will mention that the MDR/BMDR backbone will be biconnected only if the network is biconnected. (This does not affect the algorithm.) > > >Section 5.1. (Phase 1: Creating the Neighbor Connectivity Matrix) > ># Comment 14. There should be a clear indication whether the >connectivity Matrix is ()i per interface or (ii) per node. OK, I will mention that the matrix is calculated for the given interface, even though the beginning of Section 5 states that the entire MDR selection algorithm is applied per interface. > >Section 5.4. (Phase 4: Selection of the (Backup) Parent) > ># Comment 15. The step sequence in this section is not specified. There >should be a clear sequence of steps that is assured to provide no >contradictions between subsequent actions. The only required ordering is that the last paragraph (in which an MDR Other selects its Backup Parent) must be done last (after the Parent is selected), so I will add text to indicate this. > >Section 6.1. (Interface States) > ># Comment 16. Does every node in the network need to have the same >2HopRefresh? Or does it work also with various settings in the network? >This is not clear enough in the specification. There should be some text >about this. As I mentioned above, the fact that different routers can use different values of the new interface parameters (including 2HopRefresh) is made clear in the paragraph from Section 3.2 that I quoted above. In particular, some routers can use diff Hellos while others use only full Hellos (corresponding to 2HopRefresh =3D 1). > >Section 8. (Flooding Procedure) > ># Comment 17. The introduction of the term "covered" neighbor should be >in terminology. Section 8 should just specify flooding procedure, and be >more concise, for clarity purposes. Recommendation: rewrite a more >consise specification. The term "covered" is used only in Section 8 (except for one informal use that I will remove) and has a detailed definition that would not be appreciated in the terminology section. The idea is to define it just before using it, for convenience. I don't want to burden the reader with this detailed definition until it is required in Section 8. As for writing a more concise specification, I don't see how that is possible. Note that, for MANET interfaces, steps 1-7 replace steps 1-5 in Section 13.3 of RFC 2328 (which are still valid for non-MANET interfaces). I want to keep the parallelism. In both cases, these steps support multiple interfaces. > >Section 8.1 (LSA Forwarding Procedure) > >..."(5) If the router is a flooding MDR for this interface," > ># Comment 18. This brings apparent contradictions with section 2.2. Is >MDR per interface? Per node? What happens in case of multiple MANET >interfaces? Some text should specify this in the draft. As I mentioned, MDRs are selected per interface. Steps 1 through 7 are applied to each MANET interface, similar to Section 13.3 of RFC 2328, and I will add text to make this clear. > ># Comment 19. Transition between step 5 and step 6 is confusing. Step 5 >floods the LSAs, and step 6 seems to "undo" some transmissions done in >step 5? Should step 5 come in fact after step 6? If Step 5 results in the LSA being flooded out the interface, then there is no need to execute Steps 6 and 7. I will add text to make this clear. > ># Comment 20. Covered optimization (used in steps 2, 4 and 6) is very >complex, and not straightforward to implement since it is much more than >"last-hop" dependent flooding: it is "multiple neighbor's last hop" >dependent flooding. Is this mechanism really necessary, since there is >already a CDS? This was discussed long ago on the ospf-manet list. There are two main points to make. First, the flooding procedure in RFC 2328 already requires examining each neighbor when a new LSA is received (Step 1 of Section 13.3), so we are not adding any complexity. Second, it is possible to precompute the set of neighbors that cover all other neighbors, and use this information to simplify steps 2 and 6a (which do not involve BMDRs) by ignoring Acks. For example, step 2 would be replaced with the following: (2) If the received new LSA covers all bidirectional neighbors on the interface, examine the next interface. (This simplification does not apply to BMDRs, but BMDRs are optional anyway.) Instead of explicitly stating the above simplification, I will allow it simply by allowing the option of ignoring Acks in Step 2. = (I previously thought about doing this anyway.) > >Section 8.1.1 (Note on Step 6 of LSA Forwarding Procedure) > ># Comment 21. This should not be in the specification. Maybe this should >be in a "BCP" document instead? This is just an example illustrating the benefit of Step 6 of the LSA forwarding procedure. It helps people to understand why Step 6 is included. > >Section B.2. (Detailed Algorithm for Step 3.2 (BMDR Selection)) > ># Comment 22. There is an optional algorithm for BMDR computation (b) >which seems to not be recommended. So why not remove it altogether? What the draft says is that the simplified algorithm, which omits step b, is not recommended if AdjConnectivity =3D 2. Thus, step b is certainly recommended if AdjConnectivity =3D 2. Here is the paragraph that follows the algorithm: "A simplified version of the algorithm MAY be performed by omitting step (b). However, the simplified algorithm will result in more BMDRs, and is not recommended if AdjConnectivity =3D 2 since it will result in more adjacencies." >Comment 23. General comment: the specification should be more >consistent with the denomination of the different options. > > > >Comment 24. General comment: there many options. >- 4 levels of LSAFullness >- 3 levels of AdjConnectivity >- 2HopRefresh value (various differential Hellos) >- non-flooding MDR option >It would be very useful and clearer to have a table somewhere in >appendix that summarizes all the possible configurations of option >settings and which indicates which configurations are functional and >which are not. All configurations of option settings are functional and interoperable, except that minimal LSAs (LSAFullness =3D 0) cannot be used with full-topology adjacencies (AdjConnectivity =3D 0). Although this is implied in the third paragraph of Section 9.3, I will make it clearer, and also state it in Section 3.2 (New Configurable Interface Parameters). I will also add your name to the Acknowledgments section. Richard > >Best regards, >Emmanuel > > > >Abhay Roy a =E9crit : > = > >>We are starting WG Last Call of this revision of the subject draft. >> >>This drafts is intended to be Experimental status. The OSPF WG last call >>will begin today and will end at 12:00 AM EDT, October 20, 2008. >> >>Abhay/Acee >> >>-------- Original Message -------- >>Subject: I-D Action:draft-ietf-ospf-manet-mdr-02.txt >>Date: Tue, 10 Jun 2008 21:45:03 -0700 (PDT) >>From: Internet-Drafts@ietf.org >>Reply-To: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >>CC: ospf@ietf.org >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Open Shortest Path First IGP Working >>Group of the IETF. >> >> >> Title : MANET Extension of OSPF using CDS Flooding >> Author(s) : R. Ogier, et al. >> Filename : draft-ietf-ospf-manet-mdr-02.txt >> Pages : 62 >> Date : 2008-06-10 >> >>This document specifies an extension of OSPF for IPv6 to support >>mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is >>designed as a new OSPF interface type for MANETs. OSPF-MDR is based >>on the selection of a subset of MANET routers, consisting of MANET >>Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected >>dominating set (CDS), and the MDRs and Backup MDRs together form a >>biconnected CDS for robustness. This CDS is exploited in two ways. >>First, to reduce flooding overhead, an optimized flooding procedure >>is used in which only (Backup) MDRs flood new link state >>advertisements (LSAs) back out the receiving interface; reliable >>flooding is ensured by retransmitting LSAs along adjacencies. >>Second, adjacencies are formed only between (Backup) MDRs and a >>subset of their neighbors, allowing for much better scaling in dense >>networks. The CDS is constructed using 2-hop neighbor information >>provided in a Hello protocol extension. The Hello protocol is >>further optimized by allowing differential Hellos that report only >>changes in neighbor states. Options are specified for originating >>router-LSAs that provide full or partial topology information, >>allowing overhead to be reduced by advertising less topology >>information. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-02.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >>_______________________________________________ >>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 ospf-bounces@ietf.org Tue Oct 21 08:36:59 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5A23A6B71; Tue, 21 Oct 2008 08:36:59 -0700 (PDT) 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 748023A6B5C for ; Tue, 21 Oct 2008 08:36:58 -0700 (PDT) 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=[AWL=0.000, 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 fVcMWp7o3ZfG for ; Tue, 21 Oct 2008 08:36:57 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8F0963A6B44 for ; Tue, 21 Oct 2008 08:36:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,458,1220227200"; d="scan'208";a="23409352" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2008 15:38:11 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9LFcA6Y010202 for ; Tue, 21 Oct 2008 08:38:10 -0700 Received: from [10.21.75.208] ([10.21.75.208]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9LFc9aD017808 for ; Tue, 21 Oct 2008 15:38:09 GMT Message-ID: <48FDF761.6070705@cisco.com> Date: Tue, 21 Oct 2008 08:38:09 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: OSPF List References: <48EA3AFD.7040009@cisco.com> In-Reply-To: <48EA3AFD.7040009@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2994; t=1224603490; x=1225467490; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20[OSPF]=20WG=20Last=20Call=20complete=20 for=20draft-ietf-ospf-manet-mdr-02.txt |Sender:=20; bh=5pFkSPZ5gqI8XQNurOlyF364Y6nzZ2CydIlDkpmNhgU=; b=cYxsSfLIS6W+a37TTTgggqDVnL3vh1VICTeOXFho/2uxXZ7M/6rdO9dyZ/ 5FGKvF39L02cRuESa2IS4s9+up+ijcA0g1s7tirTshYSyLMZvhPErRrFA+Sh q8V3sCdxik; Authentication-Results: sj-dkim-4; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [OSPF] WG Last Call complete for draft-ietf-ospf-manet-mdr-02.txt 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Last call completed without any significant issues. Richard will publish a new version with some additional clarifications based on comments received so far. Regards, -Abhay On 10/6/2008 9:21 AM, Abhay Roy wrote: > > We are starting WG Last Call of this revision of the subject draft. > > This drafts is intended to be Experimental status. The OSPF WG last call > will begin today and will end at 12:00 AM EDT, October 20, 2008. > > Abhay/Acee > > -------- Original Message -------- > Subject: I-D Action:draft-ietf-ospf-manet-mdr-02.txt > Date: Tue, 10 Jun 2008 21:45:03 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ospf@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Open Shortest Path First IGP Working > Group of the IETF. > > > Title : MANET Extension of OSPF using CDS Flooding > Author(s) : R. Ogier, et al. > Filename : draft-ietf-ospf-manet-mdr-02.txt > Pages : 62 > Date : 2008-06-10 > > This document specifies an extension of OSPF for IPv6 to support > mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is > designed as a new OSPF interface type for MANETs. OSPF-MDR is based > on the selection of a subset of MANET routers, consisting of MANET > Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected > dominating set (CDS), and the MDRs and Backup MDRs together form a > biconnected CDS for robustness. This CDS is exploited in two ways. > First, to reduce flooding overhead, an optimized flooding procedure > is used in which only (Backup) MDRs flood new link state > advertisements (LSAs) back out the receiving interface; reliable > flooding is ensured by retransmitting LSAs along adjacencies. > Second, adjacencies are formed only between (Backup) MDRs and a > subset of their neighbors, allowing for much better scaling in dense > networks. The CDS is constructed using 2-hop neighbor information > provided in a Hello protocol extension. The Hello protocol is > further optimized by allowing differential Hellos that report only > changes in neighbor states. Options are specified for originating > router-LSAs that provide full or partial topology information, > allowing overhead to be reduced by advertising less topology > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 ospf-bounces@ietf.org Tue Oct 21 08:40:53 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3123A6995; Tue, 21 Oct 2008 08:40:53 -0700 (PDT) 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 4D8FD3A67C0 for ; Tue, 21 Oct 2008 08:40:52 -0700 (PDT) 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 9sKUmG8sMi+E for ; Tue, 21 Oct 2008 08:40:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7C2ED3A6995 for ; Tue, 21 Oct 2008 08:40:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,458,1220227200"; d="scan'208";a="179733987" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2008 15:42:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9LFg6Dt001290 for ; Tue, 21 Oct 2008 08:42:06 -0700 Received: from [10.21.75.208] ([10.21.75.208]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9LFg5fI012793 for ; Tue, 21 Oct 2008 15:42:06 GMT Message-ID: <48FDF84D.4080504@cisco.com> Date: Tue, 21 Oct 2008 08:42:05 -0700 From: Abhay Roy User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ospf@ietf.org References: <20081001213001.42FBC3A69DF@core3.amsl.com> In-Reply-To: <20081001213001.42FBC3A69DF@core3.amsl.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1616; t=1224603726; x=1225467726; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20WG=20Last=20call=20for=20draft-ietf-ospf-manet- mpr-02.txt |Sender:=20; bh=8L5uPNznnp/L5vK0Gfyft3B/lAnphaiSmWachmp50pk=; b=LkKGpgi9nuXFMCLGg/gmPr7htbv3PlDiPqZajUrk/GoHjnu6JshBdbceWo UtKQwSOmmdBImlml6DoG8TzXm69Mif8xgyeAMXXxhJwUTbfuU2Az1ISH6net dY8MR/pCjw; Authentication-Results: sj-dkim-3; header.From=akr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [OSPF] WG Last call for draft-ietf-ospf-manet-mpr-02.txt 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org We are starting WG Last Call of this revision of the subject draft. This drafts is intended to be Experimental status. The OSPF WG last call will begin today and will end at 12:00 AM EDT, Nov 4th, 2008. Abhay/Acee On 10/1/2008 2:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : OSPF MPR Extension for Ad Hoc Networks > Author(s) : E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen > Filename : draft-ietf-ospf-manet-mpr-02.txt > Pages : 30 > Date : 2008-10-1 > > This document specifies an OSPFv3 interface type tailored for mobile > ad hoc networks. This interface type is derived from the broadcast > interface type, and denoted the "OSPFv3 MANET interface type". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mpr-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Oct 26 06:05:50 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200783A6A1C; Sun, 26 Oct 2008 06:05:50 -0700 (PDT) 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 2C87E3A6A1C for ; Sun, 26 Oct 2008 06:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_50=0.001, STOX_REPLY_TYPE=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 xac6oQO1nI7k for ; Sun, 26 Oct 2008 06:05:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 12CD43A6948 for ; Sun, 26 Oct 2008 06:05:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m9QD7A6c001991; Sun, 26 Oct 2008 13:07:13 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m9QD7Ah4001985; Sun, 26 Oct 2008 13:07:10 GMT Message-ID: <003701c9376b$c0540550$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Sun, 26 Oct 2008 13:07:02 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [OSPF] Status of draft-ietf-ospf-te-node-addr-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, The repository shows this as expired. Any plans to take it to completion? Thanks, Adrian _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Oct 28 02:53:26 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13FA33A6ABD; Tue, 28 Oct 2008 02:53:26 -0700 (PDT) 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 ED3A43A694A for ; Tue, 28 Oct 2008 02:53:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRPIRsOPCJjO for ; Tue, 28 Oct 2008 02:53:14 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 515C63A6ABD for ; Tue, 28 Oct 2008 02:53:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F2A39429196; Tue, 28 Oct 2008 02:53:13 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18799-08; Tue, 28 Oct 2008 02:53:13 -0700 (PDT) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 534FE429195; Tue, 28 Oct 2008 02:53:13 -0700 (PDT) In-Reply-To: <003701c9376b$c0540550$0200a8c0@your029b8cecfe> References: <003701c9376b$c0540550$0200a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753.1) X-Priority: 3 Message-Id: <49011D79-31E6-4A3D-A138-5487DAFB5431@redback.com> From: Acee Lindem Date: Tue, 28 Oct 2008 05:53:10 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] Status of draft-ietf-ospf-te-node-addr-04.txt 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Adrian, I think we can go forward with this draft - especially now that all the OSPFv3 TE draft has become an RFC. It just needs to be refreshed and make to the top of our WG review and last call queue (authors copied). Thanks, Acee On Oct 26, 2008, at 9:07 AM, Adrian Farrel wrote: > Hi, > > The repository shows this as expired. > > Any plans to take it to completion? > > Thanks, > Adrian > _______________________________________________ > 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 ospf-bounces@ietf.org Thu Oct 30 13:39:53 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797BB3A6B17; Thu, 30 Oct 2008 13:39:53 -0700 (PDT) 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 E2BDB3A6A0E for ; Thu, 30 Oct 2008 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 rJ2Qd1UpdcvB for ; Thu, 30 Oct 2008 13:39:03 -0700 (PDT) Received: from ip2mx2.uwm.edu (ip2mx2.uwm.edu [129.89.7.80]) by core3.amsl.com (Postfix) with ESMTP id F38C83A6894 for ; Thu, 30 Oct 2008 13:39:02 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mx2.uwm.edu with ESMTP; 30 Oct 2008 15:39:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C0AF2C085C8; Thu, 30 Oct 2008 15:39:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2wQB97-TAQV; Thu, 30 Oct 2008 15:39:00 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9EBA9C085C2; Thu, 30 Oct 2008 15:39:00 -0500 (CDT) Date: Thu, 30 Oct 2008 15:39:00 -0500 (CDT) From: Mukul Goyal To: acee@redback.com, akr@cisco.com Message-ID: <1670555576.1442431225399140616.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <249498482.1437251225398584457.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.10_GA_2638.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.10_GA_2638.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ospf@ietf.org Subject: [OSPF] Request for a slot for LSA Correlation discussion 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee/Abhay I recently posted a ID on LSA correlation: http://www.cs.uwm.edu/~mukul/draft-goyal-ospf-lsacorr-00.txt I was wondering if I can get a presentation slot at the Minneapolis meeting? Thanks Mukul _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Oct 31 03:11:37 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3717F3A695C; Fri, 31 Oct 2008 03:11:37 -0700 (PDT) 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 258763A695C for ; Fri, 31 Oct 2008 03:11:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZaWQjh4N6R8 for ; Fri, 31 Oct 2008 03:11:35 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 4C74F3A688C for ; Fri, 31 Oct 2008 03:11:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6840B9B2B8F; Fri, 31 Oct 2008 03:11:34 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05527-09; Fri, 31 Oct 2008 03:11:34 -0700 (PDT) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id DB5259B2B8E; Fri, 31 Oct 2008 03:11:33 -0700 (PDT) In-Reply-To: <1670555576.1442431225399140616.JavaMail.root@mail02.pantherlink.uwm.edu> References: <1670555576.1442431225399140616.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Fri, 31 Oct 2008 06:11:31 -0400 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] Request for a slot for LSA Correlation discussion 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Mukul, Sure - we'll discuss details offline. Thanks, Acee On Oct 30, 2008, at 4:39 PM, Mukul Goyal wrote: > Hi Acee/Abhay > > I recently posted a ID on LSA correlation: > > http://www.cs.uwm.edu/~mukul/draft-goyal-ospf-lsacorr-00.txt > > I was wondering if I can get a presentation slot at the Minneapolis > meeting? > > Thanks > Mukul > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Oct 31 03:13:42 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE90E3A695C; Fri, 31 Oct 2008 03:13:42 -0700 (PDT) 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 032963A6857 for ; Fri, 31 Oct 2008 03:13:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 839YnSBk70Xt for ; Fri, 31 Oct 2008 03:13:40 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 601823A6ABC for ; Fri, 31 Oct 2008 03:13:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7DD52D2DA4A for ; Fri, 31 Oct 2008 03:13:39 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06338-04 for ; Fri, 31 Oct 2008 03:13:39 -0700 (PDT) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 3517AD2DA49 for ; Fri, 31 Oct 2008 03:13:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: To: OSPF List From: Acee Lindem Date: Fri, 31 Oct 2008 06:13:37 -0400 X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] IETF 73 OSPF WG Meeting Agenda Slots 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Please contact Abhay or me if you would like a slot on the agenda. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf