From ospf-bounces@ietf.org Sat Nov 1 06:16:34 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 CC5DC3A67D8; Sat, 1 Nov 2008 06:16:34 -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 8F1343A67D8 for ; Sat, 1 Nov 2008 06:16: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 8VzAqcIBB-Ne for ; Sat, 1 Nov 2008 06:16:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 0D9CC3A67A6 for ; Sat, 1 Nov 2008 06:16:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mA1DG3K15834; Sat, 1 Nov 2008 14:16:03 +0100 (CET) Received: from [10.55.140.83] (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mA1DFnG15727; Sat, 1 Nov 2008 14:15:49 +0100 (CET) Message-ID: <490C5688.5020202@cisco.com> Date: Sat, 01 Nov 2008 14:15:52 +0100 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Mukul Goyal References: <1670555576.1442431225399140616.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1670555576.1442431225399140616.JavaMail.root@mail02.pantherlink.uwm.edu> Cc: ospf@ietf.org 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Mukul, I don't plan attending Minneapolis meeting so I went through the paper now. Academic papers investigating possibility of considering reduced set of nodes during recalculation in link state routing protocols were done I believe in 80-th years of the last century. And identifying scope of changes and need to do recalculation is obviously integral part of each such algorithm. Furthermore, those algorithms typically consider not only the fact that vertex (i.e. 'node' in your paper) or edge ('link') went down but also if that element was actually computed as part of shortest path tree during last recalculation. Idea is that if 'link' was not used last time then tree wouldn't change if that link went down, so no need to do any recalculation. Sorry to sound unenthusiastic but it seems to me your work is not only 20 years late but it is also covering just portion of those works. The only novelty is that it is being packed as Informational RFC... Thanks, Anton 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospilot@lists.oln.org Mon Nov 3 04:33:39 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 69B973A69EB for ; Mon, 3 Nov 2008 04:33:39 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_SXLIFE=1.07, UNPARSEABLE_RELAY=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 CDINfqh7x1VD for ; Mon, 3 Nov 2008 04:33:38 -0800 (PST) Received: from ppp-77-234-230-188.dsidata.sk (ppp-77-234-230-188.dsidata.sk [77.234.230.188]) by core3.amsl.com (Postfix) with SMTP id B7F9C3A6B14 for ; Mon, 3 Nov 2008 04:33:35 -0800 (PST) Received: from Beverley Juliana (10.15.18.16) by ppp-77-234-230-188.dsidata.sk (PowerMTA(TM) v3.2r4) id hfp77o26d18j28 for ; Mon, 3 Nov 2008 01:33:33 +0100 Message-Id: <20081103023333.4743.qmail@ppp-77-234-230-188.dsidata.sk> To: Subject: RE: Message From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 3 Nov 2008 04:33:35 -0800 (PST) Men's Health Daily Dose
07/30/08
FIRE UP YOUR SEX LIFE
Get her in the mood and reap the benefits


MH Today: The Latest Health News
Mysteries of the Sexes
The MH Life
The Trainer
From ospf-bounces@ietf.org Mon Nov 3 05:01: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 4471C28C127; Mon, 3 Nov 2008 05:01:35 -0800 (PST) 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 734A428C0F7 for ; Mon, 3 Nov 2008 05:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 VYqVFKya1cfJ for ; Mon, 3 Nov 2008 05:00:08 -0800 (PST) Received: from ip2mx2.uwm.edu (ip2mx2.uwm.edu [129.89.7.80]) by core3.amsl.com (Postfix) with ESMTP id 4777B3A683A for ; Mon, 3 Nov 2008 05:00:08 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mx2.uwm.edu with ESMTP; 03 Nov 2008 07:00:06 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 22964C085C2; Mon, 3 Nov 2008 07:00:06 -0600 (CST) 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 oRPnMxLwPetG; Mon, 3 Nov 2008 07:00:03 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 82622C085C8; Mon, 3 Nov 2008 07:00:03 -0600 (CST) Date: Mon, 3 Nov 2008 07:00:03 -0600 (CST) From: Mukul Goyal To: Anton Smirnov Message-ID: <1449163157.1942891225717203362.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <490C5688.5020202@cisco.com> 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: 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Anton Thanks for your comments. The LSA correlation is not an incremental SPF algorithm. It simply means - correlate the LSAs to identify the topology change and use this event (the topology change identification) as the trigger to the state machine that determines when a routing table calculation will be done. At present, OSPF uses a new LSA as this trigger. >From your message I got the impression that some of the incremental SPF algorithms published in 1980s had LSA correlation like approach as an integral part. I would really appreciate some pointers. In my literature search, I was not able to find any previous use of an LSA Correlation like approach. Regards Mukul ----- Original Message ----- From: "Anton Smirnov" To: "Mukul Goyal" Cc: ospf@ietf.org Sent: Saturday, November 1, 2008 8:15:52 AM GMT -06:00 US/Canada Central Subject: Re: [OSPF] Request for a slot for LSA Correlation discussion Hi Mukul, I don't plan attending Minneapolis meeting so I went through the paper now. Academic papers investigating possibility of considering reduced set of nodes during recalculation in link state routing protocols were done I believe in 80-th years of the last century. And identifying scope of changes and need to do recalculation is obviously integral part of each such algorithm. Furthermore, those algorithms typically consider not only the fact that vertex (i.e. 'node' in your paper) or edge ('link') went down but also if that element was actually computed as part of shortest path tree during last recalculation. Idea is that if 'link' was not used last time then tree wouldn't change if that link went down, so no need to do any recalculation. Sorry to sound unenthusiastic but it seems to me your work is not only 20 years late but it is also covering just portion of those works. The only novelty is that it is being packed as Informational RFC... Thanks, Anton 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 3 14:23:17 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 610AB3A6C1D; Mon, 3 Nov 2008 14:23:17 -0800 (PST) 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 35A063A68DF for ; Mon, 3 Nov 2008 14:23:16 -0800 (PST) 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 duWZQKs4xC5G for ; Mon, 3 Nov 2008 14:23:15 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C4C2E28C246 for ; Mon, 3 Nov 2008 14:20:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mA3MKqj11218; Mon, 3 Nov 2008 23:20:52 +0100 (CET) Received: from [10.55.140.83] (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mA3MKbG11108; Mon, 3 Nov 2008 23:20:38 +0100 (CET) Message-ID: <490F793B.4070209@cisco.com> Date: Mon, 03 Nov 2008 23:20:43 +0100 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Mukul Goyal References: <1449163157.1942891225717203362.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1449163157.1942891225717203362.JavaMail.root@mail02.pantherlink.uwm.edu> Cc: ospf@ietf.org 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Mukul, as I wrote, SPF on subset of LSAs must somehow determine subset of LSAs affected by a change. This by definition requires analysis of change in the LSA, i.e. comparing 'old' and 'new' LSAs. In this sense "LSA correlation" is integral part of incremental SPF. I don't have pointers ready but try searching for papers by McQuillan & Rosen. Thanks, Anton Mukul Goyal wrote: > Hi Anton > > Thanks for your comments. The LSA correlation is not an incremental SPF algorithm. It simply means - correlate the LSAs to identify the topology change and use this event (the topology change identification) as the trigger to the state machine that determines when a routing table calculation will be done. At present, OSPF uses a new LSA as this trigger. > >>From your message I got the impression that some of the incremental SPF algorithms published in 1980s had LSA correlation like approach as an integral part. I would really appreciate some pointers. In my literature search, I was not able to find any previous use of an LSA Correlation like approach. > > Regards > Mukul > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 3 16:54:12 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 62CF33A6983; Mon, 3 Nov 2008 16:54:12 -0800 (PST) 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 3D0CB3A680D for ; Mon, 3 Nov 2008 16:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] 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 JZVHlNo2W7Lj for ; Mon, 3 Nov 2008 16:54:10 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 2F09A3A6983 for ; Mon, 3 Nov 2008 16:54:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BFdD5CyczxJQRyMj5pV9oRRqrad4zCf8Qk5tdogs0j4cO1CaHOgsOwuvcmLM7I0P; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.217.59] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KxABL-0002Zu-Kj for ospf@ietf.org; Mon, 03 Nov 2008 19:54:08 -0500 Message-ID: <4910460D.9000102@earthlink.net> Date: Tue, 04 Nov 2008 04:54:37 -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: ospf@ietf.org References: <48EA3AFD.7040009@cisco.com> <48FC2DBB.1000502@inria.fr> <48FDFAC2.6090101@earthlink.net> In-Reply-To: <48FDFAC2.6090101@earthlink.net> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4782dc5ff7f8a5ee123802ff55f6e3c9eb12a86d350a3af3d91350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.59 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: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org The following updated draft for OSPF-MDR has been posted: http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-03.txt The changes are as follows: o Changes in response to comments from Emmanuel Baccelli (mostly clarifications). o Added statement that a new router-LSA must be originated if the link metric has changed for an advertised MANET neighbor. o A few editorial changes. The draft should now be ready for IESG review. Richard Ogier www.manet-routing.org _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 3 17:12:45 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 454B13A6924; Mon, 3 Nov 2008 17:12:45 -0800 (PST) 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 2C96A3A6924 for ; Mon, 3 Nov 2008 17:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] 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 WxLqWiqZKJWK for ; Mon, 3 Nov 2008 17:12:43 -0800 (PST) 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 04B173A689F for ; Mon, 3 Nov 2008 17:12:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GkWFdZZW/3ShUgyAQnVz603adQ99L5hozrh/kvsZ/sttbZUT+CsMrV34IXtt33TN; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.217.59] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KxATE-0006UG-1T for ospf@ietf.org; Mon, 03 Nov 2008 20:12:40 -0500 Message-ID: <49104A63.2040901@earthlink.net> Date: Tue, 04 Nov 2008 05:13:07 -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: ospf@ietf.org References: <20081001213001.42FBC3A69DF@core3.amsl.com> <48FDF84D.4080504@cisco.com> In-Reply-To: <48FDF84D.4080504@cisco.com> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4782dc5ff7f8a5ee123ec23f16dfd5163467fc2b34ba9503630350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.59 Subject: Re: [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 Here are my comments for draft-ietf-ospf-mpr-02. First a general comment. A major change from version 01 to version 02 is that there is now one Flooding-MPR set per MANET interface (versus one set per router in version 01), while there is still one Path-MPR set per router. Since both Flooding-MPRs and Path-MPRs must become adjacent, it seems to me that it would be more efficient to just have one set of MPRs, the Path-MPRs, and use them for both flooding and LSAs. 5.4.1.1. Default LSA Flooding Algorithm ... "3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types other than OSPFv3 MANET interface. 4. If the sending OSPFv3 interface is a Flooding-MPR selector of this router, then the LSA MUST also be retransmitted over all OSPFv3 MANET interfaces concerned by the scope, with the multicast address all_SPF_Routers." # Comment 1. Since Flooding-MPRs are selected per interface, and since the 2-hop neighbor set (N2) is also defined per interface, there is no guarantee that a router that is 2 hops away, but requires using a different MANET interface for the 2nd hop, is reachable via an MPR. Thus, the above steps do not guarantee that all routers will be reached. For example, consider two MANET interfaces A and B, where A forms a network with diameter 1 and thus has no MPRs. Then an LSA originated by a router that uses only interface A will not reach a router that uses only interface B. Unless I am mistaken, this needs to be fixed. 5.2.7. Hello Packet Processing # Comment 2. It is not clear how N2 and the Flooding-MPR selector set and Path-MPR selector set are updated when a Hello is received, since details are not provided. For example, if the router receives a Hello from neighbor j, and the Hello does not list a symmetric 2-hop neighbor k, then does the router immediately delete k from N2, or does it wait until the tuple expires? (Waiting seems unnecessary and would slow down response to link failures.) Similarly, if the router receives a Hello from a Flooding-MPR selector, and the Hello does not list the router as a Flooding-MPR, does the router immediately delete the neighbor from the Flooding-MPR selector set, or does it wait until the tuple expires? Also, when a Hello packet is received, the S bit (for Synch router) needs to be examined to update a corresponding neighbor variable (which is not specified in the draft). Each router must know whether each neighbor is a Synch router, in order to know when to change the neighbor state to ExStart. Section 5.3. Adjacencies # Comment 3. Need to add that a Synch router must bring up adjacencies with all neighbors AND each router must bring up an adjacency with a neighbor that is a Synch router. But "bring up adjacency" might be too informal and imprecise. A more precise statement would say when the neighbor state must transition to ExStart. For example, if a neighbor in state 2-Way has the S bit set in its PMPR TLV, then the state must transition to ExStart. Section 5.3.2. Adjacency Conservation ... "When a router receives Hello packets from a symmetric 1-hop neighbor which ceases to list this router as being adjacent (see Section 5.2.3), ..." # Comment 4. Section 5.2.3 does not mention adjacent neighbors, so I think this should be "Section 5.2.6". Section 5.4. Link State Advertisements # Comment 5. To avoid routing loops, it is also necessary to originate a new router-LSA when the metric changes for an advertised neighbor, even if the Path-MPR set does not change. (Or you could just say that any change that affects the router-LSA contents causes a new router-LSA to be originated). Section 5.4.1. LSA Flooding # Comment 6. This section specifies how to flood an LSA that is received from a neighbor, but not how to flood an LSA that is originated by the router itself. If this is the same as RFC2328 and RFC5340, then that should be stated. "3. If the scope of the LSA is link local or reserved, the LSA MUST NOT be flooded on any interface." # Comment 7. This implies that a link-LSA is forwarded only one hop on a MANET. Therefore, the link-LSA is flooded reliably only to adjacent neighbors, not to neighbors in state 2-Way. But link-LSAs are used to advertise link-local IPv6 addresses for use in the next-hop calculation, so link-LSAs need to be flooded reliably to all bidirectional neighbors. Therefore, if Step 3 above is used, then link-LSAs are not of much use in MANETs. Maybe the best solution is to not use link-LSAs for MANET interfaces. Instead the next-hop address can be obtained from the IPv6 source address in the neighbor's Hello packet (as mentioned in RFC5340 Section 4.8.2). 5.7. Routing Table Computation "When routing table (re)computation occurs, in addition to the processing of the Link State Database defined in [RFC5340] and [RFC2328], routers which have one or more MANET interfaces MAY include links between themselves and MANET neighbors that are in state 2-Way or higher (as data and protocol packets may be sent, received and processed over these links too)." # Comment 8. First of all, by making it optional to include these links to MANET neighbors, you do NOT ensure that the computed paths will be shortest. In fact, since some routers may not have any Path-MPRs (consider a network with diameter 1), the router-LSA can be empty, and the SPF calculation would not even calculate a path to 1-hop neighbors. Therefore, "MAY" should be changed to "MUST". Also, For clarity, you should explain that bidirectional neighbors must be included even if they are not advertised in the router-LSA. # Comment 9. The phrase "include links" is vague. The description should be more precise, explaining for example what the root vertex looks like and that Step 2b (checking for a link from W back to V) must be skipped when V is the root vertex and W is not advertised. Richard P.S. I noticed that the Metric TLV (appended to each Hello) includes the cost of all neighbors on all MANET interfaces (not just the interface on which the Hello is sent). This can increase overhead significantly, but I see that it is necessary because of the use of Path-MPRs to decide which neighbors to advertise in the router-LSA. I.e., each router needs to know the minimum cost from each 2-hop neighbor even if the 2nd hop uses a different interface. The min-cost LSA method of OSPF-MDR does not require this. In OSPF-MDR, a Hello (or LLS TLV attached to it) never includes neighbors that are on a different interface. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 4 07:48:55 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 ED9093A69B8; Tue, 4 Nov 2008 07:48:54 -0800 (PST) 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 26D293A683B for ; Tue, 4 Nov 2008 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 aB6YvkLQp6AF for ; Tue, 4 Nov 2008 07:48:53 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 7A1DA3A69C3 for ; Tue, 4 Nov 2008 07:48:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,543,1220220000"; d="scan'208";a="31115057" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2008 16:48:32 +0100 Message-ID: <49106EC3.8060008@inria.fr> Date: Tue, 04 Nov 2008 16:48:19 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ospf@ietf.org X-Enigmail-Version: 0.95.7 Subject: Re: [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-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Richard, Thanks for you feedback. I will comment inline Richard Ogier a =E9crit : > > Here are my comments for draft-ietf-ospf-mpr-02. > > > > First a general comment. > > A major change from version 01 to version 02 is that there is now one > > Flooding-MPR set per MANET interface (versus one set per router in > > version 01), while there is still one Path-MPR set per router. > > Since both Flooding-MPRs and Path-MPRs must become adjacent, > > it seems to me that it would be more efficient to just have one > > set of MPRs, the Path-MPRs, and use them for both flooding and LSAs. > > Actually there is no change from version 01 to version 02 on that aspect. Version 01 was already specifying one MPR set per MANET interface, except it was not stated that explicitly in the specification. > > > > 5.4.1.1. Default LSA Flooding Algorithm > > ... > > "3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types > > other than OSPFv3 MANET interface. > > > > 4. If the sending OSPFv3 interface is a Flooding-MPR selector of > > this router, then the LSA MUST also be retransmitted over all > > OSPFv3 MANET interfaces concerned by the scope, with the > > multicast address all_SPF_Routers." > > > > # Comment 1. Since Flooding-MPRs are selected per interface, and since > > the 2-hop neighbor set (N2) is also defined per interface, there is no > > guarantee that a router that is 2 hops away, but requires using a > > different MANET interface for the 2nd hop, is reachable via an MPR. > > Thus, the above steps do not guarantee that all routers will be reached. > > For example, consider two MANET interfaces A and B, where A forms a > > network with diameter 1 and thus has no MPRs. Then an LSA originated by > > a router that uses only interface A will not reach a router that uses > > only interface B. Unless I am mistaken, this needs to be fixed. > > > > MPR flooding basically works as in OLSR, which works fine ;) However your comment points out that it is not clear enough in the draft that N2 contains all the 2 hop neighbors advertized in Hellos, including 2 hop neighbors appended in the TLVs. So we will add a sentence making this clearer. > > 5.2.7. Hello Packet Processing > > > > # Comment 2. It is not clear how N2 and the Flooding-MPR selector set > > and Path-MPR selector set are updated when a Hello is received, since > > details are not provided. For example, if the router receives a Hello > > from neighbor j, and the Hello does not list a symmetric 2-hop neighbor > > k, then does the router immediately delete k from N2, or does it wait > > until the tuple expires? (Waiting seems unnecessary and would slow > > down response to link failures.) > > Similarly, if the router receives a Hello from a Flooding-MPR selector, > > and the Hello does not list the router as a Flooding-MPR, does the > > router immediately delete the neighbor from the Flooding-MPR selector > > set, or does it wait until the tuple expires? > > As per 5.2.7, N and N2 are updated to reflect Hellos as they are received. If N or N2 has changed, the Flooding-MPR and Path-MPR sets must be recomputed. If I understand correctly, your comment is about when to delete stale info from repositories to reflect new Hello info. Deletion is of course supposed to happen immediately. So we will add a sentence that spells this out. > > Also, when a Hello packet is received, the S bit (for Synch router) > > needs to be examined to update a corresponding neighbor variable > > (which is not specified in the draft). > > Each router must know whether each neighbor is a Synch router, > > in order to know when to change the neighbor state to ExStart. > > This is specified in section 5.6, which details the use of the S bit in TLVs appended to Hellos. If a router starts receiving hellos with the S bit set from a neighbor, it must go to ExStart with this neighbor. > > Section 5.3. Adjacencies > > > > # Comment 3. Need to add that a Synch router must bring up adjacencies > > with all neighbors AND each router must bring up an adjacency with a > > neighbor that is a Synch router. But "bring up adjacency" might be > > too informal and imprecise. A more precise statement would say when > > the neighbor state must transition to ExStart. > > For example, if a neighbor in state 2-Way has the S bit set > > in its PMPR TLV, then the state must transition to ExStart. > > Again, this is specified in section 5.6. However, we will add a sentence which spells out "bringing up adjacency" into "transition into ExStart", which is indeed more precise. > > > > Section 5.3.2. Adjacency Conservation > > ... > > "When a router receives Hello packets from a symmetric 1-hop neighbor > > which ceases to list this router as being adjacent (see > > Section 5.2.3), ..." > > > > # Comment 4. Section 5.2.3 does not mention adjacent neighbors, so I > > think this should be "Section 5.2.6". > > Actually 5.2.3 specifies how adjacencies are signalled in Hellos (via node ordering in Hellos). > > > > Section 5.4. Link State Advertisements > > > > # Comment 5. To avoid routing loops, it is also necessary to originate > > a new router-LSA when the metric changes for an advertised neighbor, > > even if the Path-MPR set does not change. > > (Or you could just say that any change that affects the router-LSA > > contents causes a new router-LSA to be originated). > > You are right. We will add the sentence you suggest here. > > > > Section 5.4.1. LSA Flooding > > > > # Comment 6. This section specifies how to flood an LSA that is > > received from a neighbor, but not how to flood an LSA that is > > originated by the router itself. If this is the same as RFC2328 and > > RFC5340, then that should be stated. > > Originating a flood happens as usual: out all interfaces concerned by the scope. We will add a sentence that spells this out. > > "3. If the scope of the LSA is link local or reserved, the LSA > > MUST NOT be flooded on any interface." > > > > # Comment 7. This implies that a link-LSA is forwarded only one hop > > on a MANET. Therefore, the link-LSA is flooded reliably only to > > adjacent neighbors, not to neighbors in state 2-Way. > > But link-LSAs are used to advertise link-local IPv6 addresses > > for use in the next-hop calculation, so link-LSAs need to be > > flooded reliably to all bidirectional neighbors. > > Therefore, if Step 3 above is used, then link-LSAs are not > > of much use in MANETs. Maybe the best solution is to > > not use link-LSAs for MANET interfaces. Instead the next-hop > > address can be obtained from the IPv6 source address in the > > neighbor's Hello packet (as mentioned in RFC5340 Section 4.8.2). > > You are right, Link-LSAs are not used in MPR-OSPF. > > > > 5.7. Routing Table Computation > > > > "When routing table (re)computation occurs, in addition to the > > processing of the Link State Database defined in [RFC5340] and > > [RFC2328], routers which have one or more MANET interfaces MAY > > include links between themselves and MANET neighbors that are in > > state 2-Way or higher (as data and protocol packets may be sent, > > received and processed over these links too)." > > > > # Comment 8. First of all, by making it optional to include these links > > to MANET neighbors, you do NOT ensure that the computed paths will be > > shortest. In fact, since some routers may not have any Path-MPRs > > (consider a network with diameter 1), the router-LSA can be empty, and > > the SPF calculation would not even calculate a path to 1-hop neighbors. > > Therefore, "MAY" should be changed to "MUST". > > Also, For clarity, you should explain that bidirectional neighbors > > must be included even if they are not advertised in the router-LSA. > > Yes, we will add a sentence that is more precise. You are right this is a MUST and not a MAY, if shortest paths are wanted. > > # Comment 9. The phrase "include links" is vague. The description should > > be more precise, explaining for example what the root vertex looks like > > and that Step 2b (checking for a link from W back to V) must be skipped > > when V is the root vertex and W is not advertised. > > We will replace "include links" by a more precise expression, that will make it clearer that the connectivity matrix used to compute routes takes into account the links between the root and all its neighbors in state 2-Way and higher. cheers, Emmanuel > > Richard > > > > P.S. I noticed that the Metric TLV (appended to each Hello) includes > > the cost of all neighbors on all MANET interfaces (not just the > > interface on which the Hello is sent). > > This can increase overhead significantly, but I see that it is > > necessary because of the use of Path-MPRs to decide which neighbors > > to advertise in the router-LSA. I.e., each router needs to know > > the minimum cost from each 2-hop neighbor even if the 2nd hop uses > > a different interface. > > The min-cost LSA method of OSPF-MDR does not require this. > > In OSPF-MDR, a Hello (or LLS TLV attached to it) never includes > > neighbors that are on a different interface. > > _______________________________________________ > > 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 Nov 4 09:51:55 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 43A423A6B51; Tue, 4 Nov 2008 09:51:55 -0800 (PST) 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 03D473A6B51 for ; Tue, 4 Nov 2008 09:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] 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 t03+OYiDSZWc for ; Tue, 4 Nov 2008 09:51:52 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 2A3F63A6A07 for ; Tue, 4 Nov 2008 09:51:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=g9SaBvu1ePe8Zf8wDBt6fqi4VYXyW1wirX7jY7u1eH/tVZRF0ZfWVeZRRVa2zzRJ; 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.223.65] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KxQ49-0004LE-Gt; Tue, 04 Nov 2008 12:51:48 -0500 Message-ID: <49113492.9020209@earthlink.net> Date: Tue, 04 Nov 2008 21:52:18 -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: <49106EC3.8060008@inria.fr> In-Reply-To: <49106EC3.8060008@inria.fr> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4782dc5ff7f8a5ee123cd9f853ede455d4c8635da4aebe85d8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.223.65 Cc: ospf@ietf.org Subject: Re: [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: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Emmanuel, I have a few responses below. Emmanuel Baccelli wrote: >Hi Richard, >Thanks for you feedback. I will comment inline > > >Richard Ogier a =E9crit : > >>>Here are my comments for draft-ietf-ospf-mpr-02. >>> >>>First a general comment. >>>A major change from version 01 to version 02 is that there is now one >>>Flooding-MPR set per MANET interface (versus one set per router in >>>version 01), while there is still one Path-MPR set per router. >>>Since both Flooding-MPRs and Path-MPRs must become adjacent, >>>it seems to me that it would be more efficient to just have one >>>set of MPRs, the Path-MPRs, and use them for both flooding and LSAs. >>> >>> > > >Actually there is no change from version 01 to version 02 on that >aspect. Version 01 was already specifying one MPR set per MANET >interface, except it was not stated that explicitly in the specification. > > > >>>5.4.1.1. Default LSA Flooding Algorithm >>>... >>> "3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types >>> other than OSPFv3 MANET interface. >>> >>> 4. If the sending OSPFv3 interface is a Flooding-MPR selector of >>> this router, then the LSA MUST also be retransmitted over all >>> OSPFv3 MANET interfaces concerned by the scope, with the >>> multicast address all_SPF_Routers." >>> >>># Comment 1. Since Flooding-MPRs are selected per interface, and since >>>the 2-hop neighbor set (N2) is also defined per interface, there is no >>>guarantee that a router that is 2 hops away, but requires using a >>>different MANET interface for the 2nd hop, is reachable via an MPR. >>>Thus, the above steps do not guarantee that all routers will be reached. >>>For example, consider two MANET interfaces A and B, where A forms a >>>network with diameter 1 and thus has no MPRs. Then an LSA originated by >>>a router that uses only interface A will not reach a router that uses >>>only interface B. Unless I am mistaken, this needs to be fixed. >>> >>> >>> > > >MPR flooding basically works as in OLSR, which works fine ;) However >your comment points out that it is not clear enough in the draft that N2 >contains all the 2 hop neighbors advertized in Hellos, including 2 hop >neighbors appended in the TLVs. So we will add a sentence making this >clearer. > > I see. That means the router must also look at the Metric TLV or PMPR TLV to determine N2. This was not clear in the draft. > >>>5.2.7. Hello Packet Processing >>> >>># Comment 2. It is not clear how N2 and the Flooding-MPR selector set >>>and Path-MPR selector set are updated when a Hello is received, since >>>details are not provided. For example, if the router receives a Hello >>>from neighbor j, and the Hello does not list a symmetric 2-hop neighbor >>>k, then does the router immediately delete k from N2, or does it wait >>>until the tuple expires? (Waiting seems unnecessary and would slow >>>down response to link failures.) >>>Similarly, if the router receives a Hello from a Flooding-MPR selector, >>>and the Hello does not list the router as a Flooding-MPR, does the >>>router immediately delete the neighbor from the Flooding-MPR selector >>>set, or does it wait until the tuple expires? >>> >>> > > >As per 5.2.7, N and N2 are updated to reflect Hellos as they are >received. If N or N2 has changed, the Flooding-MPR and Path-MPR sets >must be recomputed. If I understand correctly, your comment is about >when to delete stale info from repositories to reflect new Hello info. >Deletion is of course supposed to happen immediately. So we will add a >sentence that spells this out. > > > >>>Also, when a Hello packet is received, the S bit (for Synch router) >>>needs to be examined to update a corresponding neighbor variable >>>(which is not specified in the draft). >>>Each router must know whether each neighbor is a Synch router, >>>in order to know when to change the neighbor state to ExStart. >>> >>> > > >This is specified in section 5.6, which details the use of the S bit in >TLVs appended to Hellos. If a router starts receiving hellos with the S >bit set from a neighbor, it must go to ExStart with this neighbor. > > > Section 5.6 does NOT state that if a router starts receiving Hellos with the S bit set, it must go to ExStart with the neighbor. But I assume you will add this either to Section 5.6 or 5.3. Also, you need to maintain a neighbor variable for the S bit, in order to always know whether each neighbor is a Synch router. This is needed in Section 5.3.2 (Adjacency Conservation), since the second paragraph requires the router to know whether or not a neighbor is a Synch router. >>>Section 5.3. Adjacencies >>> >>># Comment 3. Need to add that a Synch router must bring up adjacencies >>>with all neighbors AND each router must bring up an adjacency with a >>>neighbor that is a Synch router. But "bring up adjacency" might be >>>too informal and imprecise. A more precise statement would say when >>>the neighbor state must transition to ExStart. >>>For example, if a neighbor in state 2-Way has the S bit set >>>in its PMPR TLV, then the state must transition to ExStart. >>> >>> > > >Again, this is specified in section 5.6. However, we will add a sentence >which spells out "bringing up adjacency" into "transition into ExStart", >which is indeed more precise. > > > >>>Section 5.3.2. Adjacency Conservation >>>... >>> "When a router receives Hello packets from a symmetric 1-hop neighbor >>> which ceases to list this router as being adjacent (see >>> Section 5.2.3), ..." >>> >>># Comment 4. Section 5.2.3 does not mention adjacent neighbors, so I >>>think this should be "Section 5.2.6". >>> >>> > > >Actually 5.2.3 specifies how adjacencies are signalled in Hellos (via >node ordering in Hellos). > > Section 5.2.3 specifies that Flooding-MPRs must be listed before all other symmetric neighbors. But this certainly does not indicate which neighbors are adjacent. As stated in the first paragraph of 5.3.2, a neighbor may continue to be adjacent even if it is no longer an MPR or MPR selector (or Synch router). So your response is not correct. After looking at Section 5.2.6 more closely, the PMPR TLV also might not provide the required information, since it indicates which neighbors are adjacent over any MANET interface, but does not indicate which interface (if there are multiple interfaces). But I don't think this makes the protocol incorrect, since it may be OK for an unnecessary adjacency to be unidirectional (i.e., router A still considers router B to be adjacent even after Router B has torn down the adjacency). My suggestion is to use the PMPR TLV anyway, so that the router tears down the adjacency if the PMPR TLV from the neighbor does not list the router as adjacent (over any interface). Or, you can modify the Flooding-MPR Selection TLV by using the 8-bit Reserved field to indicate the number of adjacent neighbors that are not MPRs. Although this does not indicate which MPR neighbors are adjacent, this may not be necessary since such an adjacency will be re-established if it fails in either direction. Cheers, Richard >>>Section 5.4. Link State Advertisements >>> >>># Comment 5. To avoid routing loops, it is also necessary to originate >>>a new router-LSA when the metric changes for an advertised neighbor, >>>even if the Path-MPR set does not change. >>>(Or you could just say that any change that affects the router-LSA >>>contents causes a new router-LSA to be originated). >>> >>> > > >You are right. We will add the sentence you suggest here. > > > >>>Section 5.4.1. LSA Flooding >>> >>># Comment 6. This section specifies how to flood an LSA that is >>>received from a neighbor, but not how to flood an LSA that is >>>originated by the router itself. If this is the same as RFC2328 and >>>RFC5340, then that should be stated. >>> >>> > > >Originating a flood happens as usual: out all interfaces concerned by >the scope. We will add a sentence that spells this out. > > > > >>> "3. If the scope of the LSA is link local or reserved, the LSA >>> MUST NOT be flooded on any interface." >>> >>># Comment 7. This implies that a link-LSA is forwarded only one hop >>>on a MANET. Therefore, the link-LSA is flooded reliably only to >>>adjacent neighbors, not to neighbors in state 2-Way. >>>But link-LSAs are used to advertise link-local IPv6 addresses >>>for use in the next-hop calculation, so link-LSAs need to be >>>flooded reliably to all bidirectional neighbors. >>>Therefore, if Step 3 above is used, then link-LSAs are not >>>of much use in MANETs. Maybe the best solution is to >>>not use link-LSAs for MANET interfaces. Instead the next-hop >>>address can be obtained from the IPv6 source address in the >>>neighbor's Hello packet (as mentioned in RFC5340 Section 4.8.2). >>> >>> > > >You are right, Link-LSAs are not used in MPR-OSPF. > > > >>>5.7. Routing Table Computation >>> >>> "When routing table (re)computation occurs, in addition to the >>> processing of the Link State Database defined in [RFC5340] and >>> [RFC2328], routers which have one or more MANET interfaces MAY >>> include links between themselves and MANET neighbors that are in >>> state 2-Way or higher (as data and protocol packets may be sent, >>> received and processed over these links too)." >>> >>># Comment 8. First of all, by making it optional to include these links >>>to MANET neighbors, you do NOT ensure that the computed paths will be >>>shortest. In fact, since some routers may not have any Path-MPRs >>>(consider a network with diameter 1), the router-LSA can be empty, and >>>the SPF calculation would not even calculate a path to 1-hop neighbors. >>>Therefore, "MAY" should be changed to "MUST". >>>Also, For clarity, you should explain that bidirectional neighbors >>>must be included even if they are not advertised in the router-LSA. >>> >>> > > >Yes, we will add a sentence that is more precise. You are right this is >a MUST and not a MAY, if shortest paths are wanted. > > > >>># Comment 9. The phrase "include links" is vague. The description >>> >should > >>>be more precise, explaining for example what the root vertex looks like >>>and that Step 2b (checking for a link from W back to V) must be skipped >>>when V is the root vertex and W is not advertised. >>> >>> > > >We will replace "include links" by a more precise expression, that will >make it clearer that the connectivity matrix used to compute routes >takes into account the links between the root and all its neighbors in >state 2-Way and higher. > >cheers, >Emmanuel > > > >>>Richard >>> >>>P.S. I noticed that the Metric TLV (appended to each Hello) includes >>>the cost of all neighbors on all MANET interfaces (not just the >>>interface on which the Hello is sent). >>>This can increase overhead significantly, but I see that it is >>>necessary because of the use of Path-MPRs to decide which neighbors >>>to advertise in the router-LSA. I.e., each router needs to know >>>the minimum cost from each 2-hop neighbor even if the 2nd hop uses >>>a different interface. >>>The min-cost LSA method of OSPF-MDR does not require this. >>>In OSPF-MDR, a Hello (or LLS TLV attached to it) never includes >>>neighbors that are on a different interface. >>>_______________________________________________ >>>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 Tue Nov 4 11:02:45 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 E779228C278; Tue, 4 Nov 2008 11:02:45 -0800 (PST) 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 0550528C278 for ; Tue, 4 Nov 2008 11:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 6m3YhvZcU8cu for ; Tue, 4 Nov 2008 11:02:43 -0800 (PST) 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 230863A6CA7 for ; Tue, 4 Nov 2008 11:02:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,544,1220220000"; d="scan'208";a="18853957" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2008 20:01:47 +0100 Message-ID: <49109C1A.4000702@inria.fr> Date: Tue, 04 Nov 2008 20:01:46 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: ospf@ietf.org References: <49106EC3.8060008@inria.fr> <49113492.9020209@earthlink.net> In-Reply-To: <49113492.9020209@earthlink.net> X-Enigmail-Version: 0.95.7 Subject: Re: [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-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Richard, thanks. See below. Richard Ogier a =E9crit : > Emmanuel, > = > I have a few responses below. > = >> >> >> This is specified in section 5.6, which details the use of the S bit in >> TLVs appended to Hellos. If a router starts receiving hellos with the S >> bit set from a neighbor, it must go to ExStart with this neighbor. >> >> >> > Section 5.6 does NOT state that if a router starts receiving Hellos with > the S bit set, it must go to ExStart with the neighbor. > But I assume you will add this either to Section 5.6 or 5.3. > = Section 5.6 specifies that a synch router must bring up adjacencies with all its MANET neighbors. To be more precise, we will add a sentence that will make clear that "bring up adjacency" means "go to state ExStart". We will also add a sentence like "If a router receives from a neighbor Hellos with the S bit set, it must transition to Exstart with this neighbor.". This was not explicitly stated so far, you are right. > Also, you need to maintain a neighbor variable for the S bit, in order > to always know whether each neighbor is a Synch router. This is needed > in Section 5.3.2 (Adjacency Conservation), since the second paragraph > requires the router to know whether or not a neighbor is a Synch router. > = Synch routers know they are Synch routers so they transition into ExStart. And on the otehr hand, neighbors receive Hellos with the S bit set, so they also transition into ExStart. It works OK this way. This will indeed be clearer with the above explicit sentence we are going to add in Section 5.6. >> >> >> Actually 5.2.3 specifies how adjacencies are signalled in Hellos (via >> node ordering in Hellos). >> >> > Section 5.2.3 specifies that Flooding-MPRs must be listed before all other > symmetric neighbors. But this certainly does not indicate which neighbors > are adjacent. As stated in the first paragraph of 5.3.2, a neighbor > may continue to be adjacent even if it is no longer an MPR or MPR selector > (or Synch router). So your response is not correct. > = > After looking at Section 5.2.6 more closely, the PMPR TLV also might > not provide the required information, since it indicates which neighbors > are adjacent over any MANET interface, but does not indicate which > interface (if there are multiple interfaces). > But I don't think this makes the protocol incorrect, since it may be > OK for an unnecessary adjacency to be unidirectional (i.e., router A > still considers router B to be adjacent even after Router B has torn > down the adjacency). > My suggestion is to use the PMPR TLV anyway, so that the router tears > down the adjacency if the PMPR TLV from the neighbor does not list > the router as adjacent (over any interface). > = > Or, you can modify the Flooding-MPR Selection TLV by using the > 8-bit Reserved field to indicate the number of adjacent neighbors > that are not MPRs. Although this does not indicate which MPR neighbors > are adjacent, this may not be necessary since such an adjacency will > be re-established if it fails in either direction. > = Yes, the PMPR-TLV appended at the end of each hello lists which neighbors are adjacent, and which neighbors are not, as per section 5.2.6. You are correct. So we will change the reference to 5.2.6, as you suggest. cheers Emmanuel _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 4 11:46: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 8F8AE28C274; Tue, 4 Nov 2008 11:46:23 -0800 (PST) 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 3347028C274 for ; Tue, 4 Nov 2008 11:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] 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 JWVwkPkeprQA for ; Tue, 4 Nov 2008 11:46:22 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 3602528C26C for ; Tue, 4 Nov 2008 11:46:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JLgS0NubpeUWVZwc4faNmDHtCK0rU8i9dWdRcw8RViaUMP/Y8Z60+Jc9NkOuU6jX; 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.221.110] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KxRqn-0003km-Tf; Tue, 04 Nov 2008 14:46:07 -0500 Message-ID: <49114F5E.1010505@earthlink.net> Date: Tue, 04 Nov 2008 23:46:38 -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: <49106EC3.8060008@inria.fr> <49113492.9020209@earthlink.net> <49109C1A.4000702@inria.fr> In-Reply-To: <49109C1A.4000702@inria.fr> X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4782dc5ff7f8a5ee1233d1661e8f4894c93e599e20459303bb6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.110 Cc: ospf@ietf.org Subject: Re: [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: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Emmanuel, Thanks. I agree with your responses and have no further comments. Richard Emmanuel Baccelli wrote: >Hi Richard, thanks. See below. > >Richard Ogier a =E9crit : > = > >>Emmanuel, >> >>I have a few responses below. >> >> = >> >>>This is specified in section 5.6, which details the use of the S bit in >>>TLVs appended to Hellos. If a router starts receiving hellos with the S >>>bit set from a neighbor, it must go to ExStart with this neighbor. >>> >>> >>> >>> = >>> >>Section 5.6 does NOT state that if a router starts receiving Hellos with >>the S bit set, it must go to ExStart with the neighbor. >>But I assume you will add this either to Section 5.6 or 5.3. >> >> = >> > > >Section 5.6 specifies that a synch router must bring up adjacencies with >all its MANET neighbors. To be more precise, we will add a sentence that >will make clear that "bring up adjacency" means "go to state ExStart". >We will also add a sentence like "If a router receives from a neighbor >Hellos with the S bit set, it must transition to Exstart with this >neighbor.". This was not explicitly stated so far, you are right. > > > = > >>Also, you need to maintain a neighbor variable for the S bit, in order >>to always know whether each neighbor is a Synch router. This is needed >>in Section 5.3.2 (Adjacency Conservation), since the second paragraph >>requires the router to know whether or not a neighbor is a Synch router. >> >> = >> > > >Synch routers know they are Synch routers so they transition into >ExStart. And on the otehr hand, neighbors receive Hellos with the S bit >set, so they also transition into ExStart. It works OK this way. This >will indeed be clearer with the above explicit sentence we are going to >add in Section 5.6. > > > > = > >>>Actually 5.2.3 specifies how adjacencies are signalled in Hellos (via >>>node ordering in Hellos). >>> >>> >>> = >>> >>Section 5.2.3 specifies that Flooding-MPRs must be listed before all other >>symmetric neighbors. But this certainly does not indicate which neighbors >>are adjacent. As stated in the first paragraph of 5.3.2, a neighbor >>may continue to be adjacent even if it is no longer an MPR or MPR selector >>(or Synch router). So your response is not correct. >> >>After looking at Section 5.2.6 more closely, the PMPR TLV also might >>not provide the required information, since it indicates which neighbors >>are adjacent over any MANET interface, but does not indicate which >>interface (if there are multiple interfaces). >>But I don't think this makes the protocol incorrect, since it may be >>OK for an unnecessary adjacency to be unidirectional (i.e., router A >>still considers router B to be adjacent even after Router B has torn >>down the adjacency). >>My suggestion is to use the PMPR TLV anyway, so that the router tears >>down the adjacency if the PMPR TLV from the neighbor does not list >>the router as adjacent (over any interface). >> >>Or, you can modify the Flooding-MPR Selection TLV by using the >>8-bit Reserved field to indicate the number of adjacent neighbors >>that are not MPRs. Although this does not indicate which MPR neighbors >>are adjacent, this may not be necessary since such an adjacency will >>be re-established if it fails in either direction. >> >> = >> > >Yes, the PMPR-TLV appended at the end of each hello lists which >neighbors are adjacent, and which neighbors are not, as per section >5.2.6. You are correct. So we will change the reference to 5.2.6, as you >suggest. > > >cheers >Emmanuel >_______________________________________________ >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 Nov 4 12:03:39 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 D499528C2AC; Tue, 4 Nov 2008 12:03:39 -0800 (PST) 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 00CBD28C287 for ; Tue, 4 Nov 2008 12:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfhrmgh9ZAFz for ; Tue, 4 Nov 2008 12:03:37 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BC75728C2DB for ; Tue, 4 Nov 2008 12:02:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,544,1220227200"; d="scan'208";a="101597703" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2008 20:02:49 +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 mA4K2mba001719 for ; Tue, 4 Nov 2008 12:02:48 -0800 Received: from [171.70.225.89] (dhcp-171-70-225-89.cisco.com [171.70.225.89]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mA4K2mmN007947 for ; Tue, 4 Nov 2008 20:02:48 GMT Message-ID: <4910AA68.7040606@cisco.com> Date: Tue, 04 Nov 2008 12:02:48 -0800 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> <48FDF84D.4080504@cisco.com> In-Reply-To: <48FDF84D.4080504@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1995; t=1225828968; x=1226692968; 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-mpr-02.txt |Sender:=20; bh=nWhTP5aELL+uhi+/gKE3oC8Sx9HnX4+1qOQb6Ek+fOY=; b=dbebzLZNZGHzi4v5AbQJm6bHoM/V7cSYoegW+SMxlYnSDbVZEzq+JkHNWg RoSQdELytJ7wF9hNxVEaCpkrVryY/ZMIXeOSRfcHTlm/1KdWNGCAWbSMJ7TD BUEhI61Tb4; 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-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 Last call has completed. Emmanuel will refresh the draft with the comments he received. Regards, -Abhay On 10/21/2008 8:42 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, 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Nov 5 01:07:06 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 3658D3A67B5; Wed, 5 Nov 2008 01:07:06 -0800 (PST) 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 8AD583A67B5 for ; Wed, 5 Nov 2008 01:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVeU1JpIwbnF for ; Wed, 5 Nov 2008 01:07:04 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 35C9A3A67A6 for ; Wed, 5 Nov 2008 01:07:04 -0800 (PST) Received: from source ([122.248.16.22]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Nov 2008 01:07:02 PST Received: from ETSMSG-HKAV03.etsmsg.org ([10.172.40.28]) by APOUT-EDGE01.apsmtpout.emrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 16:52:29 +0800 Received: from etsmsg-hkexs01.etsmsg.org ([142.130.2.99]) by ETSMSG-HKAV03.etsmsg.org with InterScan Message Security Suite; Wed, 05 Nov 2008 17:06:58 +0800 Received: from etsmsg-hkexm05.etsmsg.org ([142.130.2.85]) by etsmsg-hkexs01.etsmsg.org with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 17:06:58 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 17:06:57 +0800 Message-ID: <89D32649C0790143AB985A5BF77A104F8400C8@etsmsg-hkexm05.etsmsg.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: checking OOBResync while flooding Thread-Index: Ack/JdqvLbslWKv+QliTtEQ9rDtL+g== From: To: X-OriginalArrivalTime: 05 Nov 2008 09:06:58.0512 (UTC) FILETIME=[DB770500:01C93F25] Subject: [OSPF] checking OOBResync while flooding 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="===============0547525224==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0547525224== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93F25.DB8D6C0B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93F25.DB8D6C0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am having a doubt on Neighbor State treatment (Section 2.5) of RFC 4811 (OSPF Out-of-Band LSDB Resynchronization) =20 Below is the extract: "Any explicit checks for the Full state of a neighbor FSM for the purposes other than LSDB synchronization and flooding should treat states ExStart, Exchange, and Loading as state Full, provided that OOBResync flag is set for the neighbor. (Flooding and MaxAge-LSA-specific procedures should not check the state of the OOBResync flag, but should continue consulting only the FSM state.)" In the first sentence it is said that during flooding, the neighbor state should be treated as Full if OOBResync flag is set and FSM states in ExStart, Exchange and Loading. =20 In the second sentence it is mentioned that while flooding, the state of OOBResync flag should not be checked and FSM state should be taken irrespective of that. =20 I see that both the sentences are contradictory. =20 thanx & regards ramana ------_=_NextPart_001_01C93F25.DB8D6C0B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am having=20 a doubt on Neighbor State treatment (Section 2.5) of = RFC = 4811 (OSPF Out-of-Band LSDB=20 Resynchronization)
 
Below is the=20 extract:
        = "Any=20 explicit checks for the Full state of a neighbor FSM for=20 the
       purposes other than LSDB=20 synchronization and flooding = should
      =20 treat states ExStart, Exchange, and Loading as state=20 Full,
       provided that OOBResync = flag is=20 set for the neighbor.  = (Flooding
      =20 and MaxAge-LSA-specific procedures should not check the state=20 of
       the OOBResync flag, but = should=20 continue consulting only the FSM
       = state.)"
In the first=20 sentence it is said that during flooding, the neighbor state should = be=20 treated as Full if OOBResync flag is set and FSM states in ExStart, = Exchange and=20 Loading.
 
In the=20 second sentence it is mentioned that while flooding, the state of = OOBResync flag=20 should not be checked and FSM state should be taken irrespective of=20 that.
 
I see that=20 both the sentences are contradictory.
 
thanx &=20 regards
ramana
------_=_NextPart_001_01C93F25.DB8D6C0B-- --===============0547525224== 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 --===============0547525224==-- From ospf-bounces@ietf.org Wed Nov 5 03:43: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 D5AF63A6B0E; Wed, 5 Nov 2008 03:43:29 -0800 (PST) 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 1D22B3A6B0E for ; Wed, 5 Nov 2008 03:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9n2bV21rcM7 for ; Wed, 5 Nov 2008 03:43:28 -0800 (PST) Received: from web57102.mail.re3.yahoo.com (web57102.mail.re3.yahoo.com [216.252.111.115]) by core3.amsl.com (Postfix) with SMTP id 08B5A3A6844 for ; Wed, 5 Nov 2008 03:43:27 -0800 (PST) Received: (qmail 4511 invoked by uid 60001); 5 Nov 2008 11:43:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=3EiwdR9wfnzb/4sQ6IYurlFGKtMmsI1urJrt+0rWZOO3KAMQNEuzuZnhPW8PScctbon3JCQxoWRBxPUrMhs15bjBCkA04/E0/7TiIWbJek7U0AmoD43/bDhKILOIvsD18xIpIgYE9+zUZvJ/gRo8OKFmEVpgalf1Z3A8FzGI9GY=; X-YMail-OSG: 5xQb55EVM1l.czc_XIUwqP2_YGFCaAMMMs3bSxAhOVBtXqLDZ79wh.xr5pH_Z0z2Jcu0NcScVfOiuNcDgTI3SnjS123wKJpd1zRRAxy8zOIi3cqBwFRtv2j_eb.M6uyPOoNnm9FPgiunrj1SIRnhY68xdH.XJs_YrrcS4y7SXGgNz1I3a28TcB1g8VU- Received: from [210.210.108.194] by web57102.mail.re3.yahoo.com via HTTP; Wed, 05 Nov 2008 03:43:18 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 5 Nov 2008 03:43:18 -0800 (PST) From: Sengottuvelan Srirangan To: Ramana.Koppula@emerson.com In-Reply-To: <89D32649C0790143AB985A5BF77A104F8400C8@etsmsg-hkexm05.etsmsg.org> MIME-Version: 1.0 Message-ID: <410749.3982.qm@web57102.mail.re3.yahoo.com> Cc: ospf@ietf.org Subject: Re: [OSPF] checking OOBResync while flooding X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sengottuvelan_s@yahoo.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164149550==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1164149550== Content-Type: multipart/alternative; boundary="0-2109238484-1225885398=:3982" --0-2109238484-1225885398=:3982 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ramana, I believe that OSPF router should not check OOBResync flag only if it is fo= r Max-Aged LSA flooding during Out-of-Band LSDB=20 Resynchronization process. ospf:- Please correct me if my understanding is wrong. Regards Sengottuvelan --- On Wed, 11/5/08, Ramana.Koppula@emerson.com wrote: From: Ramana.Koppula@emerson.com Subject: [OSPF] checking OOBResync while flooding To: ospf@ietf.org Date: Wednesday, November 5, 2008, 2:06 PM =20 Hi, =A0 I am having=20 a doubt on Neighbor State treatment (Section 2.5) of RFC 4811 (OSPF Out-of-= Band LSDB=20 Resynchronization) =A0 Below is the=20 extract: =A0=A0=A0=A0=A0=A0=A0 "Any=20 explicit checks for the Full state of a neighbor FSM for=20 the =A0=A0=A0=A0=A0=A0 purposes other than LSDB=20 synchronization and flooding should =A0=A0=A0=A0=A0=A0=20 treat states ExStart, Exchange, and Loading as state=20 Full, =A0=A0=A0=A0=A0=A0 provided that OOBResync flag is=20 set for the neighbor.=A0 (Flooding =A0=A0=A0=A0=A0=A0=20 and MaxAge-LSA-specific procedures should not check the state=20 of =A0=A0=A0=A0=A0=A0 the OOBResync flag, but should=20 continue consulting only the FSM =A0=A0=A0=A0=A0=A0=20 state.)" In the first=20 sentence it is said that during=A0flooding, the neighbor state should be=20 treated as Full if OOBResync flag is set and FSM states in ExStart, Exchang= e and=20 Loading. =A0 In the=20 second sentence it is mentioned that while flooding, the state of OOBResync= flag=20 should not be checked and FSM state should be taken irrespective of=20 that. =A0 I see that=20 both the sentences are contradictory. =A0 thanx &=20 regards ramana_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf =0A=0A=0A --0-2109238484-1225885398=:3982 Content-Type: text/html; charset=us-ascii
Hi Ramana,

I believe that OSPF router should not check OOBResync flag only if it is for Max-Aged LSA flooding during Out-of-Band LSDB Resynchronization process.

ospf:-

Please correct me if my understanding is wrong.

Regards
Sengottuvelan


--- On Wed, 11/5/08, Ramana.Koppula@emerson.com <Ramana.Koppula@emerson.com> wrote:
From: Ramana.Koppula@emerson.com <Ramana.Koppula@emerson.com>
Subject: [OSPF] checking OOBResync while flooding
To: ospf@ietf.org
Date: Wednesday, November 5, 2008, 2:06 PM

Hi,
 
I am having a doubt on Neighbor State treatment (Section 2.5) of RFC 4811 (OSPF Out-of-Band LSDB Resynchronization)
 
Below is the extract:
        "Any explicit checks for the Full state of a neighbor FSM for the
       purposes other than LSDB synchronization and flooding should
       treat states ExStart, Exchange, and Loading as state Full,
       provided that OOBResync flag is set for the neighbor.  (Flooding
       and MaxAge-LSA-specific procedures should not check the state of
       the OOBResync flag, but should continue consulting only the FSM
       state.)"
In the first sentence it is said that during flooding, the neighbor state should be treated as Full if OOBResync flag is set and FSM states in ExStart, Exchange and Loading.
 
In the second sentence it is mentioned that while flooding, the state of OOBResync flag should not be checked and FSM state should be taken irrespective of that.
 
I see that both the sentences are contradictory.
 
thanx & regards
ramana
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--0-2109238484-1225885398=:3982-- --===============1164149550== 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 --===============1164149550==-- From Mingli-abdenage@lfm-frp.com Fri Nov 7 16:13:43 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 134393A6801 for ; Fri, 7 Nov 2008 16:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.893 X-Spam-Level: X-Spam-Status: No, score=-34.893 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_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 ZBA9CULMTUN3 for ; Fri, 7 Nov 2008 16:13:42 -0800 (PST) Received: from adsl-76-192-86-118.dsl.elpstx.sbcglobal.net (adsl-76-192-86-110.dsl.elpstx.sbcglobal.net [76.192.86.110]) by core3.amsl.com (Postfix) with ESMTP id 11DE83A6B84 for ; Fri, 7 Nov 2008 16:13:41 -0800 (PST) To: Subject: urgent news From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081108001342.11DE83A6B84@core3.amsl.com> Date: Fri, 7 Nov 2008 16:13:41 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

?2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From sdasa-aenruom@lfm-frp.com Fri Nov 7 16:15:50 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 1FCD03A6801 for ; Fri, 7 Nov 2008 16:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.893 X-Spam-Level: X-Spam-Status: No, score=-45.893 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_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 SHrRcmIGiAdS for ; Fri, 7 Nov 2008 16:15:49 -0800 (PST) Received: from adsl-76-192-86-118.dsl.elpstx.sbcglobal.net (adsl-76-192-86-118.dsl.elpstx.sbcglobal.net [76.192.86.118]) by core3.amsl.com (Postfix) with ESMTP id 68C473A6818 for ; Fri, 7 Nov 2008 16:15:49 -0800 (PST) To: Subject: order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081108001549.68C473A6818@core3.amsl.com> Date: Fri, 7 Nov 2008 16:15:49 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

?2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ospf-bounces@ietf.org Fri Nov 21 11:34: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 964BE3A67A7; Fri, 21 Nov 2008 11:34:29 -0800 (PST) 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 A48933A67A7 for ; Fri, 21 Nov 2008 11:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaKRQ6ilKYZR for ; Fri, 21 Nov 2008 11:34:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF31C3A6407 for ; Fri, 21 Nov 2008 11:34:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,645,1220227200"; d="scan'208";a="199257087" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2008 19:34:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mALJYQxt009126 for ; Fri, 21 Nov 2008 11:34:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mALJYLmE026975 for ; Fri, 21 Nov 2008 19:34:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 11:34:26 -0800 Received: from pauwells-linux.cisco.com ([10.19.20.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 11:34:25 -0800 Message-ID: <49270D41.6010400@cisco.com> Date: Fri, 21 Nov 2008 13:34:25 -0600 From: Paul Wells User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: OSPF List X-OriginalArrivalTime: 21 Nov 2008 19:34:25.0970 (UTC) FILETIME=[29B53920:01C94C10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=76; t=1227296066; x=1228160066; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20IETF=2073=20OSPF=20WG=20Minutes |Sender:=20; bh=OLPlZvXR3gfM5K5hWqOoqPXjomqWYbq1S2rArBeP/Y4=; b=QVgntQh7fM3EFSHXlTWIM3YGodKMwIVqKKc7e3a1ZOatfEFhYytweJWDZb Qx7cIccHVnGLHNhWn8ATxR903uM0VA5/JV7TTzKEO7/lhg05B49rRYlG39qS v6KJrLJGyAPvMHXPyL3LlYVyBHtw0ti35bOp3Jr6qHFZ/A7D3cGL0=; Authentication-Results: sj-dkim-1; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [OSPF] IETF 73 OSPF WG Minutes 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 http://www.ietf.org/proceedings/08nov/minutes/ospf.txt Regards, Paul _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Nov 23 12:09:49 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 4E8C83A6996; Sun, 23 Nov 2008 12:09:49 -0800 (PST) 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 9FBE93A6996 for ; Sun, 23 Nov 2008 12:09:48 -0800 (PST) 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 URo5loSfu-xC for ; Sun, 23 Nov 2008 12:09:48 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 145D53A6967 for ; Sun, 23 Nov 2008 12:09:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 864D9BD0727; Sun, 23 Nov 2008 12:09:46 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15776-01; Sun, 23 Nov 2008 12:09:46 -0800 (PST) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id E79F1BD0723; Sun, 23 Nov 2008 12:09:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Sun, 23 Nov 2008 15:09:45 -0500 To: OSPF List X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.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 This starts the WG last for "Advertising a Router's Local Addresses in OSPF TE Extensions" - draft-ietf-ospf-te-node-addr-05.txt. It will conclude on Monday, December 8th, 2008 at 12:00 AM. This document was previously WG last called about 2 years back. We delayed advancing it in our to align with the ASON requirements. With the addition of the IPv4 and IPv6 prefix length, we now feel it will be usable for ASCON as well. Thanks, Acee & Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 00:49:25 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 23D733A6B96; Mon, 24 Nov 2008 00:49:25 -0800 (PST) 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 B5FA13A6B96 for ; Mon, 24 Nov 2008 00:49:23 -0800 (PST) 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 AQoNZS9zZGWG for ; Mon, 24 Nov 2008 00:49:23 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id F2ADF3A6B95 for ; Mon, 24 Nov 2008 00:49:22 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAO8nD14022609 for ; Mon, 24 Nov 2008 02:49:18 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 02:49:15 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 14:19:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 14:19:11 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOEYVjN5doBAweRa+0RWeIhxBkDA== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 24 Nov 2008 08:49:12.0562 (UTC) FILETIME=[85F53520:01C94E11] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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, RFC 4552 mandates the use of ESP (sec 3), while defines the use of AH for authenticating OSPFv3 packets as optional (it's a MAY). I might be stating the obvious but AFAIK, ESP isn't really router (or even firewall) friendly. The router cant deep inspect the ESP protected packet and filter out the ones not needed or offer prioritized treatment to OSPF packets, since it'll never know whether the payload, following the ESP header, is encrypted or not. Now, isn't this a problem? Wouldn't using AH, as opposed to ESP, help in such cases? I understand that ESP also offers encryption in addition to data integrity protection. But, is encryption really required for a routing protocol? Cheers, Manav _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 05:41:19 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 19D6F3A68DB; Mon, 24 Nov 2008 05:41:19 -0800 (PST) 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 5467B3A68DB for ; Mon, 24 Nov 2008 05:41:18 -0800 (PST) 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 WUgSXSawSO4S for ; Mon, 24 Nov 2008 05:41:17 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by core3.amsl.com (Postfix) with ESMTP id 5E7013A6889 for ; Mon, 24 Nov 2008 05:41:17 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2382323fkq.5 for ; Mon, 24 Nov 2008 05:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QQyVe4mh0Z68PjdK+u5U6NwALikdi2qmUJ3PKcdJMtU=; b=Ccc8bQlSV+pvZ0co80ScwrZdQqhG0Q1jcdxThp1IQ7d9/ijWEhXPz+YWmO9uUovoBB UrOmLApiN1gKBwl+5J6mX8HVobcmC4sIR4pFpkRh9i/VL+REryOsDPF9nD/5LJLi8iJp K0ZejWzyUW1MXGHUGBJGffYqYgKx+cmi6GRNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MHMeDQ1I35VKGEmeEh9fnWTQOkiHiKT9QId/JmcPnvmjtL78ZahuemNWJo3k/BOyEW oZm/+WwAYH+wev6NL2smW0cEQnTZRmO/gK0Uodpky98NkOw14OOnemnIj39dVLy2SEGc bpmDUOjG6wPJG6qMuoXGgeYREuPP6cewPHjYs= Received: by 10.181.208.11 with SMTP id k11mr1128290bkq.180.1227534073969; Mon, 24 Nov 2008 05:41:13 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 05:41:13 -0800 (PST) Message-ID: <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> Date: Mon, 24 Nov 2008 05:41:13 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Manav, For IPsec support AH itself is a MAY and ESP is a MUST support (if I remember correctly). Thanks, Vishwas On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) wrote: > > Hi, > > RFC 4552 mandates the use of ESP (sec 3), while defines the use of AH > for authenticating OSPFv3 packets as optional (it's a MAY). > > I might be stating the obvious but AFAIK, ESP isn't really router (or > even firewall) friendly. The router cant deep inspect the ESP protected > packet and filter out the ones not needed or offer prioritized treatment > to OSPF packets, since it'll never know whether the payload, following > the ESP header, is encrypted or not. > > Now, isn't this a problem? > > Wouldn't using AH, as opposed to ESP, help in such cases? I understand > that ESP also offers encryption in addition to data integrity > protection. But, is encryption really required for a routing protocol? > > Cheers, Manav > > > _______________________________________________ > 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 Nov 24 05:55:10 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 6AD0E3A68BD; Mon, 24 Nov 2008 05:55:10 -0800 (PST) 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 91B593A67E6 for ; Mon, 24 Nov 2008 05:55:09 -0800 (PST) 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 vsLVkhBt71-5 for ; Mon, 24 Nov 2008 05:55:08 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id D2C893A68BD for ; Mon, 24 Nov 2008 05:55:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 18015DDC22B; Mon, 24 Nov 2008 05:55:07 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18757-04; Mon, 24 Nov 2008 05:55:06 -0800 (PST) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 5ADAFDDC229; Mon, 24 Nov 2008 05:55:06 -0800 (PST) In-Reply-To: <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Mon, 24 Nov 2008 08:55:06 -0500 To: "Vishwas Manral" X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Vishwas, Manav, That is my understanding as well. Note that since OSPF is an IGP, the OSPF routing domain is normally under a single administrative domain. Hence, firewall considerations normally shouldn't come into play. Thanks, Acee On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: > Hi Manav, > > For IPsec support AH itself is a MAY and ESP is a MUST support (if I > remember correctly). > > Thanks, > Vishwas > > On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) > wrote: >> >> Hi, >> >> RFC 4552 mandates the use of ESP (sec 3), while defines the use of AH >> for authenticating OSPFv3 packets as optional (it's a MAY). >> >> I might be stating the obvious but AFAIK, ESP isn't really router (or >> even firewall) friendly. The router cant deep inspect the ESP >> protected >> packet and filter out the ones not needed or offer prioritized >> treatment >> to OSPF packets, since it'll never know whether the payload, >> following >> the ESP header, is encrypted or not. >> >> Now, isn't this a problem? >> >> Wouldn't using AH, as opposed to ESP, help in such cases? I >> understand >> that ESP also offers encryption in addition to data integrity >> protection. But, is encryption really required for a routing >> protocol? >> >> Cheers, Manav >> >> >> _______________________________________________ >> 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 Nov 24 07:13: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 9A8173A6A24; Mon, 24 Nov 2008 07:13:00 -0800 (PST) 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 330C53A6A24 for ; Mon, 24 Nov 2008 07:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mETAC6xzPnr for ; Mon, 24 Nov 2008 07:12:58 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E37203A6A1C for ; Mon, 24 Nov 2008 07:12:57 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mAOFDo9w014488; Mon, 24 Nov 2008 09:14:30 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 09:12:51 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 20:42:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 20:42:43 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOPEVk2X1d9GucTJafh1YeNT/TJAACmfFQ References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Acee Lindem" , "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 15:12:44.0609 (UTC) FILETIME=[1A34EB10:01C94E47] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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, I was more interested in the issue of the receiving router being unable to identify and classify (basically prioritize) OSPFv3 packets when ESP encapsulation is being used (which is a MUST in 4552). The only way a router can do this is, if it assumes OSPF traffic over ESP-NULL SA. Imposing such a restriction would obviously be a trifle odd. However, if AH is used, then there are no such issues, as its easy to identify, and thus offer preferential treatment to OSPFv3 packets. > domain. Hence, firewall considerations normally shouldn't come into > play. I agree. However, in some exceptional cases (mostly very secure environments) we can have firewalls being used within the network as well as the edges. Anyways, we can leave the firewalls aside as what I am more interested in is the former case (prioritizing OSPFv3 packets). Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Monday, November 24, 2008 7.25 PM > To: Vishwas Manral > Cc: Bhatia, Manav (Manav); ospf@ietf.org > Subject: Re: [OSPF] Doubt in RFC 4552 - > Authentication/Confidentiality for OSPFv3 > > Hi Vishwas, Manav, > > That is my understanding as well. Note that since OSPF is an > IGP, the > OSPF routing domain is normally under a single administrative > domain. Hence, firewall considerations normally shouldn't come into > play. > > Thanks, > Acee > > On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: > > > Hi Manav, > > > > For IPsec support AH itself is a MAY and ESP is a MUST support (if I > > remember correctly). > > > > Thanks, > > Vishwas > > > > On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) > > wrote: > >> > >> Hi, > >> > >> RFC 4552 mandates the use of ESP (sec 3), while defines > the use of AH > >> for authenticating OSPFv3 packets as optional (it's a MAY). > >> > >> I might be stating the obvious but AFAIK, ESP isn't really > router (or > >> even firewall) friendly. The router cant deep inspect the ESP > >> protected > >> packet and filter out the ones not needed or offer prioritized > >> treatment > >> to OSPF packets, since it'll never know whether the payload, > >> following > >> the ESP header, is encrypted or not. > >> > >> Now, isn't this a problem? > >> > >> Wouldn't using AH, as opposed to ESP, help in such cases? I > >> understand > >> that ESP also offers encryption in addition to data integrity > >> protection. But, is encryption really required for a routing > >> protocol? > >> > >> Cheers, Manav > >> > >> > >> _______________________________________________ > >> 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 Nov 24 08:52:38 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 ADC3C3A6876; Mon, 24 Nov 2008 08:52:38 -0800 (PST) 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 9FFFC3A6876 for ; Mon, 24 Nov 2008 08:52:37 -0800 (PST) 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 2oL57INcmFeC for ; Mon, 24 Nov 2008 08:52:36 -0800 (PST) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by core3.amsl.com (Postfix) with ESMTP id 3E68B3A681D for ; Mon, 24 Nov 2008 08:52:35 -0800 (PST) Received: by bwz6 with SMTP id 6so81120bwz.13 for ; Mon, 24 Nov 2008 08:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gOtDoke1/Ty07CaR/xYYQt6XKs8tthyxSBozpUHC0t4=; b=Wb8P3qGCZF0qgaHXa1Fm9nsyg8GmppRLMwnp1/pZRsxyd3nMxvcIY2r01QretJZzJg ZYXUV18Kraty+w8vZJptvZSA4WHp9/HR7DeUKHCQwS+d1augW2qdDAGxfJ/vhEl8Acrd TUjQCnGeBMGJmkHS8ugH2WGKdXsEge3d0lyAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Hd8fcTRB81ufDbn716qxXsELiTQZGs11nd1ymaahzGN3iWQki014OqvzQyv4dLBHUF EtBit9z+ygB16wdRVVvYiWp1wvdVksKR39F8IA74YmU52IrLswx8cejT7EIY4voLX1q5 80lCTlLnj/XU1/MU8/2dRU1bpCWCDeyZpI3ao= Received: by 10.180.224.4 with SMTP id w4mr1182109bkg.174.1227545551656; Mon, 24 Nov 2008 08:52:31 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 08:52:31 -0800 (PST) Message-ID: <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> Date: Mon, 24 Nov 2008 08:52:31 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Manav, Now that is confusing. Before I get into the specifics let me tell you that IPsecme WG is working on seeing if it will be helpful to make ESP middlebox friendly (firewall is not the only middlebox). That said we can use hueristic mechanisms to look deeper into the packet and then figure out if the packet is an encrypted/ unencrypted packet. We use something similar in the case of MPLS ECMP case. There are a couple of proposals in IPsecme already on having middlebox friendly ESP. On Mon, Nov 24, 2008 at 7:12 AM, Bhatia, Manav (Manav) wrote: > Hi Acee, > > I was more interested in the issue of the receiving router being unable > to identify and classify (basically prioritize) OSPFv3 packets when ESP > encapsulation is being used (which is a MUST in 4552). The only way a > router can do this is, if it assumes OSPF traffic over ESP-NULL SA. > Imposing such a restriction would obviously be a trifle odd. However, if > AH is used, then there are no such issues, as its easy to identify, and > thus offer preferential treatment to OSPFv3 packets. The idea of having the priority in the IP layer is that the application does not need to look deeper into the packet to figure out the priority. Why is it not possible to have different priority of OSPF packets in the IP header? That said the receiving router has the SA configured and can figure out if the packet is encrypted or not and then prioritize after that. >> domain. Hence, firewall considerations normally shouldn't come into >> play. I guess we have discussed this further. Thanks, Vishwas > > I agree. However, in some exceptional cases (mostly very secure > environments) we can have firewalls being used within the network as > well as the edges. Anyways, we can leave the firewalls aside as what I > am more interested in is the former case (prioritizing OSPFv3 packets). > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee@redback.com] >> Sent: Monday, November 24, 2008 7.25 PM >> To: Vishwas Manral >> Cc: Bhatia, Manav (Manav); ospf@ietf.org >> Subject: Re: [OSPF] Doubt in RFC 4552 - >> Authentication/Confidentiality for OSPFv3 >> >> Hi Vishwas, Manav, >> >> That is my understanding as well. Note that since OSPF is an >> IGP, the >> OSPF routing domain is normally under a single administrative >> domain. Hence, firewall considerations normally shouldn't come into >> play. >> >> Thanks, >> Acee >> >> On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: >> >> > Hi Manav, >> > >> > For IPsec support AH itself is a MAY and ESP is a MUST support (if I >> > remember correctly). >> > >> > Thanks, >> > Vishwas >> > >> > On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) >> > wrote: >> >> >> >> Hi, >> >> >> >> RFC 4552 mandates the use of ESP (sec 3), while defines >> the use of AH >> >> for authenticating OSPFv3 packets as optional (it's a MAY). >> >> >> >> I might be stating the obvious but AFAIK, ESP isn't really >> router (or >> >> even firewall) friendly. The router cant deep inspect the ESP >> >> protected >> >> packet and filter out the ones not needed or offer prioritized >> >> treatment >> >> to OSPF packets, since it'll never know whether the payload, >> >> following >> >> the ESP header, is encrypted or not. >> >> >> >> Now, isn't this a problem? >> >> >> >> Wouldn't using AH, as opposed to ESP, help in such cases? I >> >> understand >> >> that ESP also offers encryption in addition to data integrity >> >> protection. But, is encryption really required for a routing >> >> protocol? >> >> >> >> Cheers, Manav >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 08:54:31 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 A449C3A6AA0; Mon, 24 Nov 2008 08:54:31 -0800 (PST) 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 B775D3A6AA0 for ; Mon, 24 Nov 2008 08:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB4Fpm4bewt7 for ; Mon, 24 Nov 2008 08:54:29 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 8803E3A6876 for ; Mon, 24 Nov 2008 08:54:28 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2452707fkq.5 for ; Mon, 24 Nov 2008 08:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=PV2LU1Vua7nVafCW7KzGsn7T+/iwXhPyDvPKYXV3bzw=; b=gAIPEFWMjHzjGLAwzrFwj6LsAMcZxtmtTZ03io4DC2Zc55wdt0fl6eUNvKNZWsIun8 7vitnrwz2tCACsKVSUZkGxA6fEvLpJZdT0u/1zfJdNTHqj611+pbL04QKSvKR4KupyOi NZn3aTnZGXLo5BYgTA8s2qbftuqQX/bl0CPLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Rc0Dk0CosBnCsp+ukNLl1JDfE+Vw5oWCNUAYgx9TkZ+Zrh/QDbk6lvA+gkjPQgWiYq y7o7CbOEMi/bLfEeaIxnr3d2Ri+D77DLMaH3VbxARFmHvbEZivai6LyrQ87jIZ8gztHY eH6afrU4ChUfan84nTNK63mWHAfSMT11aElCs= Received: by 10.180.224.4 with SMTP id w4mr1182650bkg.174.1227545665861; Mon, 24 Nov 2008 08:54:25 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 08:54:25 -0800 (PST) Message-ID: <77ead0ec0811240854k484a816ev1174cab27c054a5@mail.gmail.com> Date: Mon, 24 Nov 2008 08:54:25 -0800 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> Cc: OSPF List Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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, On Mon, Nov 24, 2008 at 5:55 AM, Acee Lindem wrote: > Hi Vishwas, Manav, > > That is my understanding as well. Note that since OSPF is an IGP, the OSPF > routing domain is normally under a single administrative domain. Hence, > firewall considerations normally shouldn't come into play. This is not totally correct in my view. An OSPF packet sent from outside the domain should be identifiable and dropped. Thanks, Vishwas > > Thanks, > Acee > > On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: > >> Hi Manav, >> >> For IPsec support AH itself is a MAY and ESP is a MUST support (if I >> remember correctly). >> >> Thanks, >> Vishwas >> >> On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) >> wrote: >>> >>> Hi, >>> >>> RFC 4552 mandates the use of ESP (sec 3), while defines the use of AH >>> for authenticating OSPFv3 packets as optional (it's a MAY). >>> >>> I might be stating the obvious but AFAIK, ESP isn't really router (or >>> even firewall) friendly. The router cant deep inspect the ESP protected >>> packet and filter out the ones not needed or offer prioritized treatment >>> to OSPF packets, since it'll never know whether the payload, following >>> the ESP header, is encrypted or not. >>> >>> Now, isn't this a problem? >>> >>> Wouldn't using AH, as opposed to ESP, help in such cases? I understand >>> that ESP also offers encryption in addition to data integrity >>> protection. But, is encryption really required for a routing protocol? >>> >>> Cheers, Manav >>> >>> >>> _______________________________________________ >>> 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 Nov 24 09:32:15 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 945903A68F6; Mon, 24 Nov 2008 09:32:15 -0800 (PST) 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 0A7F43A68F6 for ; Mon, 24 Nov 2008 09:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ8PHaAFrvfb for ; Mon, 24 Nov 2008 09:32:13 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 233213A68BD for ; Mon, 24 Nov 2008 09:32:13 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAOHVXOx023205; Mon, 24 Nov 2008 11:32:09 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 11:31:59 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 23:01:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 23:01:53 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOVQ4fiDZwvk1zTQCzvZDs4yJ9AgAADT8A References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 17:31:55.0521 (UTC) FILETIME=[8BBCF710:01C94E5A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Vishwas, > > router can do this is, if it assumes OSPF traffic over ESP-NULL SA. > > Imposing such a restriction would obviously be a trifle > odd. However, if > > AH is used, then there are no such issues, as its easy to > identify, and > > thus offer preferential treatment to OSPFv3 packets. > The idea of having the priority in the IP layer is that the > application does not need to look deeper into the packet to figure out > the priority. Why is it not possible to have different priority of > OSPF packets in the IP header? That said the receiving router has the Yup, works in theory but I have seldom seen OSPF packets being sent with a unique TOS/Traffic value that sets them apart from other packets in the network. Moreover, you would want to prioritize OSPF traffic without any explicit configuration. Setting a unique traffic class/TOS for OSPF entails explicit user config. > SA configured and can figure out if the packet is encrypted or not and > then prioritize after that. Obviously there are other proprietary ways to prioritize ESP protected OSPFv3 packets, but they've got their own issues .. Cheers, Manav > > >> domain. Hence, firewall considerations normally shouldn't > come into > >> play. > I guess we have discussed this further. > > Thanks, > Vishwas > > > > I agree. However, in some exceptional cases (mostly very secure > > environments) we can have firewalls being used within the network as > > well as the edges. Anyways, we can leave the firewalls > aside as what I > > am more interested in is the former case (prioritizing > OSPFv3 packets). > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee@redback.com] > >> Sent: Monday, November 24, 2008 7.25 PM > >> To: Vishwas Manral > >> Cc: Bhatia, Manav (Manav); ospf@ietf.org > >> Subject: Re: [OSPF] Doubt in RFC 4552 - > >> Authentication/Confidentiality for OSPFv3 > >> > >> Hi Vishwas, Manav, > >> > >> That is my understanding as well. Note that since OSPF is an > >> IGP, the > >> OSPF routing domain is normally under a single administrative > >> domain. Hence, firewall considerations normally shouldn't > come into > >> play. > >> > >> Thanks, > >> Acee > >> > >> On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: > >> > >> > Hi Manav, > >> > > >> > For IPsec support AH itself is a MAY and ESP is a MUST > support (if I > >> > remember correctly). > >> > > >> > Thanks, > >> > Vishwas > >> > > >> > On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> RFC 4552 mandates the use of ESP (sec 3), while defines > >> the use of AH > >> >> for authenticating OSPFv3 packets as optional (it's a MAY). > >> >> > >> >> I might be stating the obvious but AFAIK, ESP isn't really > >> router (or > >> >> even firewall) friendly. The router cant deep inspect the ESP > >> >> protected > >> >> packet and filter out the ones not needed or offer prioritized > >> >> treatment > >> >> to OSPF packets, since it'll never know whether the payload, > >> >> following > >> >> the ESP header, is encrypted or not. > >> >> > >> >> Now, isn't this a problem? > >> >> > >> >> Wouldn't using AH, as opposed to ESP, help in such cases? I > >> >> understand > >> >> that ESP also offers encryption in addition to data integrity > >> >> protection. But, is encryption really required for a routing > >> >> protocol? > >> >> > >> >> Cheers, Manav > >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 09:36: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 24C2F3A6BAE; Mon, 24 Nov 2008 09:36:51 -0800 (PST) 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 DBA923A6BAE for ; Mon, 24 Nov 2008 09:36:49 -0800 (PST) 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 YignYogHmkXx for ; Mon, 24 Nov 2008 09:36:49 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 887673A6A46 for ; Mon, 24 Nov 2008 09:36:48 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1726848fga.41 for ; Mon, 24 Nov 2008 09:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nUvz6KsPuiEMAAj4xXvVj8T6Aa1SD9gbPn2IlleVQjw=; b=R0x+bw3zIPmoyEVpP/cIQe9FsxPVKNrVoJ7+4swVhgVgBGRMpHZQI4pc+OyDIrQtct 3xh8+0si1nVpBChXVXS6sFcK06bHObbR9Edg+JwmY/yy3Fn9gPPZB73KBgNAtYNH1S1q ZuLj2qpfG2p01KgYSX7Otjw2SEEcHhoiquVak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Z9N/o+AKoN4RLqULBYyjCDATVOGZpiATBZCUsoDjhIabJ2Kq8eOx9Ev3dpdVbw8vTq BQg2h3udECRA75ORztS10kBWaSZ9ZtkNU28znmuCCNf2BBco/z5PsSvOG/SYb9l2pTLi NpJnStKILIFVbA2a5dnFKa0L9sWuEc6MXRrRk= Received: by 10.180.255.1 with SMTP id c1mr1211337bki.36.1227548204951; Mon, 24 Nov 2008 09:36:44 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 09:36:44 -0800 (PST) Message-ID: <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> Date: Mon, 24 Nov 2008 09:36:44 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Manav, >> > router can do this is, if it assumes OSPF traffic over ESP-NULL SA. >> > Imposing such a restriction would obviously be a trifle >> odd. However, if >> > AH is used, then there are no such issues, as its easy to >> identify, and >> > thus offer preferential treatment to OSPFv3 packets. > >> The idea of having the priority in the IP layer is that the >> application does not need to look deeper into the packet to figure out >> the priority. Why is it not possible to have different priority of >> OSPF packets in the IP header? That said the receiving router has the > > Yup, works in theory but I have seldom seen OSPF packets being sent with > a unique TOS/Traffic value that sets them apart from other packets in > the network. Moreover, you would want to prioritize OSPF traffic without > any explicit configuration. Setting a unique traffic class/TOS for OSPF > entails explicit user config. User config - why would anyone require user config? Well it will be done when the need for it really comes, because the mechanism to do it exists. >> SA configured and can figure out if the packet is encrypted or not and >> then prioritize after that. > > Obviously there are other proprietary ways to prioritize ESP protected > OSPFv3 packets, but they've got their own issues .. Ok. Thanks, Vishwas > Cheers, Manav > >> >> >> domain. Hence, firewall considerations normally shouldn't >> come into >> >> play. >> I guess we have discussed this further. >> >> Thanks, >> Vishwas >> > >> > I agree. However, in some exceptional cases (mostly very secure >> > environments) we can have firewalls being used within the network as >> > well as the edges. Anyways, we can leave the firewalls >> aside as what I >> > am more interested in is the former case (prioritizing >> OSPFv3 packets). >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Acee Lindem [mailto:acee@redback.com] >> >> Sent: Monday, November 24, 2008 7.25 PM >> >> To: Vishwas Manral >> >> Cc: Bhatia, Manav (Manav); ospf@ietf.org >> >> Subject: Re: [OSPF] Doubt in RFC 4552 - >> >> Authentication/Confidentiality for OSPFv3 >> >> >> >> Hi Vishwas, Manav, >> >> >> >> That is my understanding as well. Note that since OSPF is an >> >> IGP, the >> >> OSPF routing domain is normally under a single administrative >> >> domain. Hence, firewall considerations normally shouldn't >> come into >> >> play. >> >> >> >> Thanks, >> >> Acee >> >> >> >> On Nov 24, 2008, at 8:41 AM, Vishwas Manral wrote: >> >> >> >> > Hi Manav, >> >> > >> >> > For IPsec support AH itself is a MAY and ESP is a MUST >> support (if I >> >> > remember correctly). >> >> > >> >> > Thanks, >> >> > Vishwas >> >> > >> >> > On Mon, Nov 24, 2008 at 12:49 AM, Bhatia, Manav (Manav) >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> RFC 4552 mandates the use of ESP (sec 3), while defines >> >> the use of AH >> >> >> for authenticating OSPFv3 packets as optional (it's a MAY). >> >> >> >> >> >> I might be stating the obvious but AFAIK, ESP isn't really >> >> router (or >> >> >> even firewall) friendly. The router cant deep inspect the ESP >> >> >> protected >> >> >> packet and filter out the ones not needed or offer prioritized >> >> >> treatment >> >> >> to OSPF packets, since it'll never know whether the payload, >> >> >> following >> >> >> the ESP header, is encrypted or not. >> >> >> >> >> >> Now, isn't this a problem? >> >> >> >> >> >> Wouldn't using AH, as opposed to ESP, help in such cases? I >> >> >> understand >> >> >> that ESP also offers encryption in addition to data integrity >> >> >> protection. But, is encryption really required for a routing >> >> >> protocol? >> >> >> >> >> >> Cheers, Manav >> >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 09:54:15 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 2EC673A68BD; Mon, 24 Nov 2008 09:54:15 -0800 (PST) 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 D91E03A68BD for ; Mon, 24 Nov 2008 09:54:13 -0800 (PST) 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 qbMF6oXFMlUl for ; Mon, 24 Nov 2008 09:54:13 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1496D3A6876 for ; Mon, 24 Nov 2008 09:54:12 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mAOHs7YT009741; Mon, 24 Nov 2008 11:54:07 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 11:54:07 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 23:24:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 23:24:02 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOW2Lq1yuQ8OhbRme1hk22XHaM1QAAISxg References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 17:54:03.0509 (UTC) FILETIME=[A347DA50:01C94E5D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Vishwas, > >> The idea of having the priority in the IP layer is that the > >> application does not need to look deeper into the packet > to figure out > >> the priority. Why is it not possible to have different priority of > >> OSPF packets in the IP header? That said the receiving > router has the > > > > Yup, works in theory but I have seldom seen OSPF packets > being sent with > > a unique TOS/Traffic value that sets them apart from other > packets in > > the network. Moreover, you would want to prioritize OSPF > traffic without > > any explicit configuration. Setting a unique traffic > class/TOS for OSPF > > entails explicit user config. > User config - why would anyone require user config? Well it will be > done when the need for it really comes, because the mechanism to do it > exists. How else would you assign a unique priority to all OSPF packets? There isn't any standard value that disambiguates OSPFv3 from other v6 packets. Or are you proposing that we use one? Cheers, Manav _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 09:57:32 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 01B523A6876; Mon, 24 Nov 2008 09:57:32 -0800 (PST) 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 0A9413A679C for ; Mon, 24 Nov 2008 09:57:30 -0800 (PST) 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 11BQSYhjGQkE for ; Mon, 24 Nov 2008 09:57:29 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id C6E8C3A6876 for ; Mon, 24 Nov 2008 09:57:28 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so2341151mue.9 for ; Mon, 24 Nov 2008 09:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uhvK2yJuaT3c7Y1bALY2li7qNEtYcs9yRo8JNuKNWyM=; b=EJd0F93ZaS4DrY/Ji4my4cAj9ayby8uycDNN20nP2eIQeo10tFgox/0095T+5oHHC+ /DXgYLd0jKZz96jqCKkq6zhZnXx6nu40XT8d9QU8i13UnKnmMAZyB0SlpWREVPy33C7r UO6AfVInimcW+9IC4SxQ74FHgMHj5dmbTbCb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qrudmc870FGv6wLWdLq1P/1QRqjcrGqCCw0wvcT5tZyySZNnQ7R5rsV2laQWe5bi5Q 22yrIMrM9cbq76jm44YT06l2yimK44It1EJByqNjyWBaaAsVrp36z6UpZIyxUXA8p6FK DG6houpOaT7Wpcd93mPdUYTDFfLbSjVsjUUbo= Received: by 10.181.201.18 with SMTP id d18mr1208348bkq.125.1227549445733; Mon, 24 Nov 2008 09:57:25 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 09:57:25 -0800 (PST) Message-ID: <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> Date: Mon, 24 Nov 2008 09:57:25 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Manav, Just as the hardware does not see OSPFv3 each kind of packet and then prioritizes it. We will just set the field in the IPv6 header by calling the right socket API's. To do that you can use the standard library cmsg interface - which is really flexible unlike the older socket interfaces we had. You do not need to do anything at the IP layer at all. Thanks, Vishwas On Mon, Nov 24, 2008 at 9:54 AM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > >> >> The idea of having the priority in the IP layer is that the >> >> application does not need to look deeper into the packet >> to figure out >> >> the priority. Why is it not possible to have different priority of >> >> OSPF packets in the IP header? That said the receiving >> router has the >> > >> > Yup, works in theory but I have seldom seen OSPF packets >> being sent with >> > a unique TOS/Traffic value that sets them apart from other >> packets in >> > the network. Moreover, you would want to prioritize OSPF >> traffic without >> > any explicit configuration. Setting a unique traffic >> class/TOS for OSPF >> > entails explicit user config. > >> User config - why would anyone require user config? Well it will be >> done when the need for it really comes, because the mechanism to do it >> exists. > > How else would you assign a unique priority to all OSPF packets? There > isn't any standard value that disambiguates OSPFv3 from other v6 > packets. Or are you proposing that we use one? > > Cheers, Manav > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 09:59: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 D28813A6876; Mon, 24 Nov 2008 09:59:59 -0800 (PST) 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 1BA413A6B94 for ; Mon, 24 Nov 2008 09:59:58 -0800 (PST) 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 KJj4bTpWcQ7r for ; Mon, 24 Nov 2008 09:59:57 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3F7C53A6876 for ; Mon, 24 Nov 2008 09:59:57 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAOHxr5e003963; Mon, 24 Nov 2008 11:59:53 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 11:59:53 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 23:29:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 23:29:48 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOXh57yhaNhKbLTgeAJGBabfmWIgAACgbw References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 17:59:50.0046 (UTC) FILETIME=[71D533E0:01C94E5E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Vishwas, > Just as the hardware does not see OSPFv3 each kind of packet and then > prioritizes it. We will just set the field in the IPv6 header by > calling the right socket API's. Yes, but for interoperability all the vendors need to use the same value, which means it needs to get standardized. Cheers, Manav > > To do that you can use the standard library cmsg interface - which is > really flexible unlike the older socket interfaces we had. You do not > need to do anything at the IP layer at all. > > Thanks, > Vishwas > > On Mon, Nov 24, 2008 at 9:54 AM, Bhatia, Manav (Manav) > wrote: > > Hi Vishwas, > > > >> >> The idea of having the priority in the IP layer is that the > >> >> application does not need to look deeper into the packet > >> to figure out > >> >> the priority. Why is it not possible to have different > priority of > >> >> OSPF packets in the IP header? That said the receiving > >> router has the > >> > > >> > Yup, works in theory but I have seldom seen OSPF packets > >> being sent with > >> > a unique TOS/Traffic value that sets them apart from other > >> packets in > >> > the network. Moreover, you would want to prioritize OSPF > >> traffic without > >> > any explicit configuration. Setting a unique traffic > >> class/TOS for OSPF > >> > entails explicit user config. > > > >> User config - why would anyone require user config? Well it will be > >> done when the need for it really comes, because the > mechanism to do it > >> exists. > > > > How else would you assign a unique priority to all OSPF > packets? There > > isn't any standard value that disambiguates OSPFv3 from other v6 > > packets. Or are you proposing that we use one? > > > > Cheers, Manav > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 10:01:45 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 4EAEA3A6821; Mon, 24 Nov 2008 10:01:45 -0800 (PST) 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 08AAE3A6821 for ; Mon, 24 Nov 2008 10:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87g4QZ7HCH6d for ; Mon, 24 Nov 2008 10:01:44 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id CA6043A679C for ; Mon, 24 Nov 2008 10:01:43 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1733160fga.41 for ; Mon, 24 Nov 2008 10:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AZhLgjU0Xu99IJMbfm6bJBjF50FgUjCEv5TT0bVIizw=; b=pnlGImJOCuPKX+H8d/yrE4+VLMt22rcyA+E2c6ZILoSxw+VfmtR5N9QNNy/NCpRQL0 lma8jR2BvjGZjpXH5CzVbwbMNKU88bhTRcBJWi2amOa4JPH9Scqf4KUe4wkRVbofgBz3 t3oJ+YMNqSfnWzLs/s1RhuAcXyaiBu8rwngso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kp6953ty2bQL7LeIsbCFac4UxBREMb5Xiub4RHnVeEBnEyVwrjMYeD74WlVJDNbV9J 45nwQSeF35ZjU9E53kdLrvEAkqk2NQhET7E2nxllrrhE+C0PgVd082/dplAxLxJfzjfZ z2L8YRirihs/GFZxeRdZw1CLzmRbeOuWJWsOc= Received: by 10.181.199.7 with SMTP id b7mr1203333bkq.193.1227549698885; Mon, 24 Nov 2008 10:01:38 -0800 (PST) Received: by 10.181.24.20 with HTTP; Mon, 24 Nov 2008 10:01:38 -0800 (PST) Message-ID: <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> Date: Mon, 24 Nov 2008 10:01:38 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Manav, I am confused. >> Just as the hardware does not see OSPFv3 each kind of packet and then >> prioritizes it. We will just set the field in the IPv6 header by >> calling the right socket API's. > > Yes, but for interoperability all the vendors need to use the same > value, which means it needs to get standardized. I guess we are clearer about the user interface now. What needs to be standardized and why? Thanks, Vishwas > Cheers, Manav > >> >> To do that you can use the standard library cmsg interface - which is >> really flexible unlike the older socket interfaces we had. You do not >> need to do anything at the IP layer at all. >> >> Thanks, >> Vishwas >> >> On Mon, Nov 24, 2008 at 9:54 AM, Bhatia, Manav (Manav) >> wrote: >> > Hi Vishwas, >> > >> >> >> The idea of having the priority in the IP layer is that the >> >> >> application does not need to look deeper into the packet >> >> to figure out >> >> >> the priority. Why is it not possible to have different >> priority of >> >> >> OSPF packets in the IP header? That said the receiving >> >> router has the >> >> > >> >> > Yup, works in theory but I have seldom seen OSPF packets >> >> being sent with >> >> > a unique TOS/Traffic value that sets them apart from other >> >> packets in >> >> > the network. Moreover, you would want to prioritize OSPF >> >> traffic without >> >> > any explicit configuration. Setting a unique traffic >> >> class/TOS for OSPF >> >> > entails explicit user config. >> > >> >> User config - why would anyone require user config? Well it will be >> >> done when the need for it really comes, because the >> mechanism to do it >> >> exists. >> > >> > How else would you assign a unique priority to all OSPF >> packets? There >> > isn't any standard value that disambiguates OSPFv3 from other v6 >> > packets. Or are you proposing that we use one? >> > >> > Cheers, Manav >> > >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Nov 24 10:12: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 6E2853A6BBA; Mon, 24 Nov 2008 10:12:47 -0800 (PST) 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 353BF3A6BAF for ; Mon, 24 Nov 2008 10:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqUTvnM2tXGJ for ; Mon, 24 Nov 2008 10:12:45 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 441D63A6BAD for ; Mon, 24 Nov 2008 10:12:44 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAOICd1k009610; Mon, 24 Nov 2008 12:12:39 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 12:12:39 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 23:42:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 23:42:35 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 thread-index: AclOXrvFKDYfmAQVQfS3OvXqEezWJQAAJCYw References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <77ead0ec0811240541x770819cax88883a37cde04754@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 18:12:36.0619 (UTC) FILETIME=[3ABEF5B0:01C94E60] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 Vishwas, > I am confused. So am I! :-) > > Yes, but for interoperability all the vendors need to use the same > > value, which means it needs to get standardized. > I guess we are clearer about the user interface now. What needs to be > standardized and why? I have a feeling that we're talking about different things here. Lets take this offline and do our bit to reduce our carbon footprint! Cheers, Manav _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ajmanfet@eim.ae Mon Nov 24 11:10:34 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 4FE2B3A699E for ; Mon, 24 Nov 2008 11:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.76 X-Spam-Level: **** X-Spam-Status: No, score=4.76 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396] 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 GHPhOnvtZrUr for ; Mon, 24 Nov 2008 11:10:33 -0800 (PST) Received: from domail2.emirates.net.ae (domail2.emirates.net.ae [213.42.1.94]) by core3.amsl.com (Postfix) with ESMTP id CD92A3A679C for ; Mon, 24 Nov 2008 11:10:31 -0800 (PST) MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Received: from dpmail2.emirates.net.ae ([213.42.1.69]) by domail2.emirates.net.ae (I&ES Mail Server 4.2) with ESMTP id <0KAU00078QIRNJ00@domail2.emirates.net.ae> for ospf-archive@lists.ietf.org; Mon, 24 Nov 2008 23:08:51 +0400 (GST) Received: from dellnotebook (ner-as21619.alshamil.net.ae [217.164.245.29]) by dpmail2.emirates.net.ae (I&ES Mail Server 4.2) with SMTP id <0KAU00C97QJRKU00@dpmail2.emirates.net.ae> for ospf-archive@lists.ietf.org; Mon, 24 Nov 2008 23:09:28 +0400 (GST) Organization: ajmanfet@eim.ae Reply-to: ajmanfet@eim.ae Message-id: <8e940df77576faa527f9c22d0012dd0a@eim.ae> From: "ajmanfet@eim.ae" To: ospf-archive@lists.ietf.org Subject: =?windows-1252?Q?Spares_for_Fanuc_Robocut_a_series_a_=96_OB_/_a_-1B,_Model_No._B-68744E/01_Wirecut_Machine?= Date: Mon, 24 Nov 2008 22:18:12 +0400 Content-transfer-encoding: quoted-printable

Subject :=20

Spares for Fanuc Robocut a series a = =96=20 OB / a -1B, Model No. = B-68744E/01=20 Wirecut Machine

Dear Sir,

Our Comapny is based in = Dubai=20 United Arab Emirates. Our Machine is=20 Fanuc=20 Robocut a series a =96 OB / a -1B, = Model No.=20 B-68744E/01 and manufactured in 1994.

We request you to = supply us the=20 Following Parts: Please quote us price and Delivery Schedule as soon as=20 Possible.

1) Die Guide (lower)=20 0.25mm           &nb= sp;            =          =20  3 PCS

2) Die Guide (Upper)=20 0.25mm           &nb= sp;            =         =20  3 PCS

3) Electrode Pin=20             &nb= sp;            =             &nb= sp;            =     =20 20 PCS

4) Jet=20 Pipe            = ;            &n= bsp;            = ;            &n= bsp;            = ;  =20   2 PCS

5) Feed Roller=20             &nb= sp;            =             &nb= sp;            =        =20   2 PCS

6) Zero Point Setting=20 Nozzles           &n= bsp;            = ;         =20  2 PCS

7) Adjustment=20 Ring            = ;            &n= bsp;            = ;            &n= bsp;=20   1 PCS

8)=20 Filter           &nb= sp;            =             &nb= sp;            =             &nb= sp;        =20   6 PCS

Your response by return will = be highly appreciated.

From ospf-bounces@ietf.org Tue Nov 25 04:34:45 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 10D1E28C0EE; Tue, 25 Nov 2008 04:34:45 -0800 (PST) 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 AADC628C0DD for ; Tue, 25 Nov 2008 04:34:43 -0800 (PST) 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 eUshe4eL8JFy for ; Tue, 25 Nov 2008 04:34:43 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id C6C0E28C0EE for ; Tue, 25 Nov 2008 04:34:42 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b6so1032807ana.4 for ; Tue, 25 Nov 2008 04:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Kxmk4TnYpm/6ZCquFCvQU3YNEaC1TgEdn04EvI6stlA=; b=OoniTDotqXGoS4t+sMwGHr0Bc+lRVGEnmOLrMr+nr7ULdzJ1pUkuVXrWtH7qrtxGYs jT5hNSMLNVBzWXXxTS/lXhV3De+gJUK578VFNE3TZ53qeLfyQq9DE2NfBBJ/oMooKaI4 BC+Tmry8hjAKg2pHdDVczilKLUSXHeH3aklvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BBUmH/DOS9mpQSu+cbuQW8C89lHbM64dLkCDcZX49qA70HoaMl3+094UNowcYLdGIG n9S4R7ymRA6yEiFS/Vs0XXUBAHeh+KXpHzYbpRx2uxVsX1abNYurEGjerg1OQfQWOv89 EKFe2AS14y9XtCktRGjLWWK3vgQVU5DVHBcw8= Received: by 10.100.126.15 with SMTP id y15mr2229095anc.123.1227616479360; Tue, 25 Nov 2008 04:34:39 -0800 (PST) Received: by 10.100.178.13 with HTTP; Tue, 25 Nov 2008 04:34:39 -0800 (PST) Message-ID: Date: Tue, 25 Nov 2008 23:34:39 +1100 From: "Abuse 007" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com> <77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality for OSPFv3 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 If a user was to set up OSPFv3 protected by ESP and wanted to prioritize OSPFv3 traffic, then they can use pre-classify QoS, the outer IP header will be marked based on the contents inside the ESP payload. Priority / low-latency queuing can then be used based on the markings on the outer header, despite the payload being encrypted. On Tue, Nov 25, 2008 at 5:12 AM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > >> I am confused. > > So am I! :-) > >> > Yes, but for interoperability all the vendors need to use the same >> > value, which means it needs to get standardized. >> I guess we are clearer about the user interface now. What needs to be >> standardized and why? > > I have a feeling that we're talking about different things here. Lets > take this offline and do our bit to reduce our carbon footprint! > > Cheers, Manav > _______________________________________________ > 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 Nov 25 06:25:57 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 8A0413A6BF1; Tue, 25 Nov 2008 06:25:57 -0800 (PST) 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 432DA3A6864 for ; Tue, 25 Nov 2008 06:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUCW4vYEzu2o for ; Tue, 25 Nov 2008 06:25:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4629E3A684B for ; Tue, 25 Nov 2008 06:25:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,664,1220227200"; d="scan'208";a="29041907" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Nov 2008 14:25:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAPEPqPH012603; Tue, 25 Nov 2008 09:25:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAPEPqup025520; Tue, 25 Nov 2008 14:25:52 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 09:25:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 09:25:51 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640711E153@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 Thread-Index: AclO+jdmWJdWf1pTR8WVSKv10MF8ggADy/mQ References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com><6D26D1FE43A66F439F8109CDD42419650235651C@INEXC1U01.in.lucent.com><77ead0ec0811240852q5d160167o3d94023b73c36483@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com><77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com><77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com><77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> From: "Stan Ratliff (sratliff)" To: "Abuse 007" , "Bhatia, Manav (Manav)" X-OriginalArrivalTime: 25 Nov 2008 14:25:52.0569 (UTC) FILETIME=[B8836A90:01C94F09] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1622; t=1227623152; x=1228487152; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[OSPF]=20Doubt=20in=20RFC=204552=20-=20 Authentication/Confidentiality=20forOSPFv3 |Sender:=20 |To:=20=22Abuse=20007=22=20,=0A=20=20=2 0=20=20=20=20=20=22Bhatia,=20Manav=20(Manav)=22=20; bh=jxtsOjjbIbiB+lQKg+pKO3YmVWStJXaKFP42gbXrlSc=; b=COGCS1juDzUT7fRMO2fWGFxkZetUYgba8ur1qKMTguv0QMYRqFb7xWMIsn U/vC2ahkxhBHX/+fG9Oi7sdjS8Dxx6QWKrtkIIdZcSpWlQNa+hTkh6VRdZZz HvTPB7L7Dw; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 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 I understand that IPsec ESP could be used. But the additional header is a very unwelcome thing in a MANET (not to mention the additional configuration complexity). Regards, Stan -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Abuse 007 Sent: Tuesday, November 25, 2008 7:35 AM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 If a user was to set up OSPFv3 protected by ESP and wanted to prioritize OSPFv3 traffic, then they can use pre-classify QoS, the outer IP header will be marked based on the contents inside the ESP payload. Priority / low-latency queuing can then be used based on the markings on the outer header, despite the payload being encrypted. On Tue, Nov 25, 2008 at 5:12 AM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > >> I am confused. > > So am I! :-) > >> > Yes, but for interoperability all the vendors need to use the same >> > value, which means it needs to get standardized. >> I guess we are clearer about the user interface now. What needs to be >> standardized and why? > > I have a feeling that we're talking about different things here. Lets > take this offline and do our bit to reduce our carbon footprint! > > Cheers, Manav > _______________________________________________ > 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 Tue Nov 25 09:14:19 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 50C753A6C01; Tue, 25 Nov 2008 09:14:19 -0800 (PST) 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 795B83A692A for ; Tue, 25 Nov 2008 09:14:17 -0800 (PST) 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 JKZ7eYtLRlBB for ; Tue, 25 Nov 2008 09:14:16 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 3F6F53A6808 for ; Tue, 25 Nov 2008 09:14:16 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so30231fga.41 for ; Tue, 25 Nov 2008 09:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sENOLD21Rv5tdgBCwLmTL3P/j7JO16pTaKNpTi0Y9EI=; b=lWbKjt3FOYZb8T+JQIVNQ1cVtazrjZHchp4Hrvdj/McSqUerqlRUo3NmR8EBjNkdLi 8hZdUeLQ9yzL1B/UL5k+NL1XFrhGzFGonVTs5/g+lpYgigMXaYS345z28p/A1MjFSGfY swb4hln9rENSVhtVGSzxl5SMOXP5M+f6CXPIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I22oSUENOwGDPvR6H5RC+jYDf+MwszreoHIHxGcpszT/OP+rzm8Z1euvwny5udNEZC YOvl97eqk6WjnnlPQWrBkxu0MQA1A9o+VNO2N350+Up9KZqSidYn+tlYxoDUucwgo6/n Zjbwx5Ne4umWViqpKNW2fUy0rZx2Zza1sBOQE= Received: by 10.180.250.5 with SMTP id x5mr1600486bkh.145.1227633253213; Tue, 25 Nov 2008 09:14:13 -0800 (PST) Received: by 10.181.147.16 with HTTP; Tue, 25 Nov 2008 09:14:13 -0800 (PST) Message-ID: <77ead0ec0811250914g4a3e9e8bi4b52a6fbea7694e2@mail.gmail.com> Date: Tue, 25 Nov 2008 09:14:13 -0800 From: "Vishwas Manral" To: "Stan Ratliff (sratliff)" In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640711E153@xmb-rtp-208.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> <7FB7EE0A621BA44B8B69E5F0A09DC7640711E153@xmb-rtp-208.amer.cisco.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 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 Stan, Are you talking about using IPsec in the tunnel mode (which is a MUST for IPsec) or are you talking about the ESP header itself? Thanks, Vishwas On Tue, Nov 25, 2008 at 6:25 AM, Stan Ratliff (sratliff) wrote: > I understand that IPsec ESP could be used. But the additional header > is a very unwelcome thing in a MANET (not to mention the additional > configuration complexity). > > Regards, > Stan > > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Abuse 007 > Sent: Tuesday, November 25, 2008 7:35 AM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org > Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality > forOSPFv3 > > If a user was to set up OSPFv3 protected by ESP and wanted to > prioritize OSPFv3 traffic, then they can use pre-classify QoS, the > outer IP header will be marked based on the contents inside the ESP > payload. Priority / low-latency queuing can then be used based on the > markings on the outer header, despite the payload being encrypted. > > On Tue, Nov 25, 2008 at 5:12 AM, Bhatia, Manav (Manav) > wrote: >> Hi Vishwas, >> >>> I am confused. >> >> So am I! :-) >> >>> > Yes, but for interoperability all the vendors need to use the same >>> > value, which means it needs to get standardized. >>> I guess we are clearer about the user interface now. What needs to be >>> standardized and why? >> >> I have a feeling that we're talking about different things here. Lets >> take this offline and do our bit to reduce our carbon footprint! >> >> Cheers, Manav >> _______________________________________________ >> 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 > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 25 10:12:05 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 0A76C3A6902; Tue, 25 Nov 2008 10:12:05 -0800 (PST) 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 2B2133A6902 for ; Tue, 25 Nov 2008 10:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jABzu0DbAK02 for ; Tue, 25 Nov 2008 10:12:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0A3843A6972 for ; Tue, 25 Nov 2008 10:12:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,665,1220227200"; d="scan'208";a="29039767" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Nov 2008 18:11:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAPIBig3020881; Tue, 25 Nov 2008 13:11:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAPIBiBD016220; Tue, 25 Nov 2008 18:11:44 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:11:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 13:11:43 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640711E2E3@xmb-rtp-208.amer.cisco.com> In-Reply-To: <77ead0ec0811250914g4a3e9e8bi4b52a6fbea7694e2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 Thread-Index: AclPIUjHCAHG7JNRTlaMQ64zleAmQwAB1UIg References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> <7FB7EE0A621BA44B8B69E5F0A09DC7640711E153@xmb-rtp-208.amer.cisco.com> <77ead0ec0811250914g4a3e9e8bi4b52a6fbea7694e2@mail.gmail.com> From: "Stan Ratliff (sratliff)" To: "Vishwas Manral" X-OriginalArrivalTime: 25 Nov 2008 18:11:44.0661 (UTC) FILETIME=[46308C50:01C94F29] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2813; t=1227636704; x=1228500704; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[OSPF]=20Doubt=20in=20RFC=204552=20-=20 Authentication/Confidentiality=20forOSPFv3 |Sender:=20 |To:=20=22Vishwas=20Manral=22=20; bh=oivGeQLNgptoXEbtZz+5sUTHCGrcL5PzrfsDteJx7i8=; b=M7PiiyqaOm7vE9MUFCNe2qkpJlszqqCOLx/FBwINLZxdj5qrp0P/YAObY/ oEwgP8KopbiZxNtQe7P/mUVrOvaIK+FyOwB6rkmUe8gjiDej1K0rt5LgpQiw Cf8OiOtcQO; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 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 Vishwas, The short answer is "yes"... ;-) With MANETs running on bandwidth-constrained, high loss links, any increase in packet size increases the probability of an error during transmission. So from my perspective, I'd like to be able to authenticate OSPF packets, but do so with the smallest possible increase in packet size, and the smallest amount of configuration on the router. Regards, Stan -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, November 25, 2008 12:14 PM To: Stan Ratliff (sratliff) Cc: Abuse 007; Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 Hi Stan, Are you talking about using IPsec in the tunnel mode (which is a MUST for IPsec) or are you talking about the ESP header itself? Thanks, Vishwas On Tue, Nov 25, 2008 at 6:25 AM, Stan Ratliff (sratliff) wrote: > I understand that IPsec ESP could be used. But the additional header > is a very unwelcome thing in a MANET (not to mention the additional > configuration complexity). > > Regards, > Stan > > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Abuse 007 > Sent: Tuesday, November 25, 2008 7:35 AM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org > Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality > forOSPFv3 > > If a user was to set up OSPFv3 protected by ESP and wanted to > prioritize OSPFv3 traffic, then they can use pre-classify QoS, the > outer IP header will be marked based on the contents inside the ESP > payload. Priority / low-latency queuing can then be used based on the > markings on the outer header, despite the payload being encrypted. > > On Tue, Nov 25, 2008 at 5:12 AM, Bhatia, Manav (Manav) > wrote: >> Hi Vishwas, >> >>> I am confused. >> >> So am I! :-) >> >>> > Yes, but for interoperability all the vendors need to use the same >>> > value, which means it needs to get standardized. >>> I guess we are clearer about the user interface now. What needs to be >>> standardized and why? >> >> I have a feeling that we're talking about different things here. Lets >> take this offline and do our bit to reduce our carbon footprint! >> >> Cheers, Manav >> _______________________________________________ >> 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 > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Nov 25 11:11:45 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 CB4183A6C1D; Tue, 25 Nov 2008 11:11:45 -0800 (PST) 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 B5A723A698F for ; Tue, 25 Nov 2008 11:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r89UXCRBJ8aQ for ; Tue, 25 Nov 2008 11:11:43 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id B081A3A6C1D for ; Tue, 25 Nov 2008 11:11:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B2946696; Tue, 25 Nov 2008 11:11:41 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31951-04; Tue, 25 Nov 2008 11:11:41 -0800 (PST) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 1A0DF698; Tue, 25 Nov 2008 11:11:40 -0800 (PST) In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640711E2E3@xmb-rtp-208.amer.cisco.com> References: <6D26D1FE43A66F439F8109CDD424196502356465@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356540@INEXC1U01.in.lucent.com> <77ead0ec0811240936l79c28d77vabf25e54403c9aed@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356543@INEXC1U01.in.lucent.com> <77ead0ec0811240957h7fe7bee0w967c569267c18ee1@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356545@INEXC1U01.in.lucent.com> <77ead0ec0811241001t7688f2a4m2dac8c3f780492ba@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356548@INEXC1U01.in.lucent.com> <7FB7EE0A621BA44B8B69E5F0A09DC7640711E153@xmb-rtp-208.amer.cisco.com> <77ead0ec0811250914g4a3e9e8bi4b52a6fbea7694e2@mail.gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC7640711E2E3@xmb-rtp-208.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <26D7BD38-A8AB-40F6-9222-4635E1798931@redback.com> From: Acee Lindem Date: Tue, 25 Nov 2008 14:11:41 -0500 To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.753.1) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality forOSPFv3 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 Stan, On Nov 25, 2008, at 1:11 PM, Stan Ratliff (sratliff) wrote: > Vishwas, > > The short answer is "yes"... ;-) With MANETs running > on bandwidth-constrained, high loss links, any increase > in packet size increases the probability of an error during > transmission. Then I suppose you don't like IPsec AH any better :^) > > So from my perspective, I'd like to be able to authenticate > OSPF packets, but do so with the smallest possible increase > in packet size, and the smallest amount of configuration on > the router. I don't know if you've followed MIP6, (now MEXT), but a similar discussion keeps recurring there. Heretofore, the result has been to stay with IPsec although other authentication mechanisms have been implemented to the chagrin of the Security area (see RFC 4285). Thanks, Acee > > Regards, > Stan > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 25, 2008 12:14 PM > To: Stan Ratliff (sratliff) > Cc: Abuse 007; Bhatia, Manav (Manav); ospf@ietf.org > Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/Confidentiality > forOSPFv3 > > Hi Stan, > > Are you talking about using IPsec in the tunnel mode (which is a MUST > for IPsec) or are you talking about the ESP header itself? > > Thanks, > Vishwas > > On Tue, Nov 25, 2008 at 6:25 AM, Stan Ratliff (sratliff) > wrote: >> I understand that IPsec ESP could be used. But the additional header >> is a very unwelcome thing in a MANET (not to mention the additional >> configuration complexity). >> >> Regards, >> Stan >> >> >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of >> Abuse 007 >> Sent: Tuesday, November 25, 2008 7:35 AM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Doubt in RFC 4552 - Authentication/ >> Confidentiality >> forOSPFv3 >> >> If a user was to set up OSPFv3 protected by ESP and wanted to >> prioritize OSPFv3 traffic, then they can use pre-classify QoS, the >> outer IP header will be marked based on the contents inside the ESP >> payload. Priority / low-latency queuing can then be used based on the >> markings on the outer header, despite the payload being encrypted. >> >> On Tue, Nov 25, 2008 at 5:12 AM, Bhatia, Manav (Manav) >> wrote: >>> Hi Vishwas, >>> >>>> I am confused. >>> >>> So am I! :-) >>> >>>>> Yes, but for interoperability all the vendors need to use the same >>>>> value, which means it needs to get standardized. >>>> I guess we are clearer about the user interface now. What needs to > be >>>> standardized and why? >>> >>> I have a feeling that we're talking about different things here. >>> Lets >>> take this offline and do our bit to reduce our carbon footprint! >>> >>> Cheers, Manav >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 mink@alienware.com Sat Nov 29 06:35:43 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 7ECAA3A63D3 for ; Sat, 29 Nov 2008 06:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.445 X-Spam-Level: X-Spam-Status: No, score=-35.445 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 PnhFkBoCzK1F for ; Sat, 29 Nov 2008 06:35:42 -0800 (PST) Received: from e178141183.adsl.alicedsl.de (e178141183.adsl.alicedsl.de [85.178.141.183]) by core3.amsl.com (Postfix) with SMTP id 3A60E3A67AE for ; Sat, 29 Nov 2008 06:35:40 -0800 (PST) To: Subject: proof you're not small-pen loser From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129143541.3A60E3A67AE@core3.amsl.com> Date: Sat, 29 Nov 2008 06:35:40 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From martin@133sh.com Sun Nov 30 16:26:35 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 807293A67EF for ; Sun, 30 Nov 2008 16:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.013 X-Spam-Level: X-Spam-Status: No, score=-38.013 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_UK=1.749, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 TB2maSgPL7GL for ; Sun, 30 Nov 2008 16:26:34 -0800 (PST) Received: from accountantcareers.co.uk (unknown [189.35.94.144]) by core3.amsl.com (Postfix) with SMTP id 0E7443A69DC for ; Sun, 30 Nov 2008 16:26:30 -0800 (PST) To: Subject: add meat to the friend From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201002632.0E7443A69DC@core3.amsl.com> Date: Sun, 30 Nov 2008 16:26:30 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052