From ospf-bounces@ietf.org Sat Mar 1 19:44:18 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 AD7BA28C3AA; Sat, 1 Mar 2008 19:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eot39SixL-PV; Sat, 1 Mar 2008 19:44:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150033A6857; Sat, 1 Mar 2008 19:44:13 -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 8B4303A6785 for ; Sat, 1 Mar 2008 19:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 VQeOlQpGctSp for ; Sat, 1 Mar 2008 19:44:07 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id DC5F03A68D3 for ; Sat, 1 Mar 2008 19:44:06 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m223hw801124; Sat, 1 Mar 2008 22:43:58 -0500 (EST) Received: from [10.83.216.146] (rtp-cpignata-vpn1.cisco.com [10.83.216.146]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id m223iau24242; Sat, 1 Mar 2008 22:44:36 -0500 (EST) Message-ID: <47CA227D.5050706@cisco.com> Date: Sat, 01 Mar 2008 22:43:57 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Subbaiah Venkata References: <44ED058B21DF294ABE394CABE5C1B52102658572@EXCH-CLUSTER-03.force10networks.com> <47C7F8B0.5060200@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Cc: OSPF List Subject: Re: [OSPF] draft-venkata-ospf-dynamic-hostname-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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Please find two additional small comment inline. On 2/29/2008 7:15 PM, Subbaiah Venkata said the following: > Hi Anton, > > Great questions. Some of them we already thought but deferred for WG > consensus. > Answers inline. > > On Fri, Feb 29, 2008 at 4:21 AM, Anton Smirnov > wrote: > > Hi all, > have a comment on this draft (OK, it's not WG document yet but hope > that's not a problem). > The document doesn't stipulate that Dynamic Hostname TLV can be > present at most once. > In addition to the scope clarifications from below, we can also explicitly mention one TLV per RI LSA. > > Yes. I think it is better to keep it simple by mandating one Dynamic > hostname TLV per originator. > This saves unnecessary flooding and network bandwidth. > > > Also, if implementation chooses to announce both > AS and area scope RI LSA then it is not clear if it is allowed to > announce different names. > > > Again, one TLV per originator. If a router is originating at least one > AS scope LSA > (for example, an ASBR originating AS external LSAs) then it should > generate AS scope > Dynamic hostname TLV. Otherwise it should originate area scope TLV. > > > > > I personally would prefer 1:1 mapping between ID and router's name > to be required but some people might disagree with me. Either way > document should specify if multiple names are allowed or not. > > > We will include some wording on these in the next revision of the draft. > > > > If we are to send text string then document should specify what > exactly is understood by 'text'. Is it ASCII or UTF-8 encoding? Are > symbols like 0x1 or 0xAF allowed? > > > We discussed and deferred this for WG consensus. > I prefer ASCII text unless there is a strong reason for UTF-8 or UNICODE. We'd like to get thoughts and opinions on this, as likely arguments for both encoding in US-ASCII and UTF-8 charsets can be made. E.g., a hostname as a globally/widely visible name would use US-ASCII [RFC2277], etc. Thanks, --Carlos. > > Thanks for the review. > > Venkata. > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Mar 3 10:16:16 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 AFAF93A6DC2; Mon, 3 Mar 2008 10:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foAX2U6y8Fah; Mon, 3 Mar 2008 10:16:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CF03A6B52; Mon, 3 Mar 2008 10:16: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 E1E363A6C37 for ; Mon, 3 Mar 2008 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 d38v25+nJE-H for ; Mon, 3 Mar 2008 10:16:04 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 80B713A69FC for ; Mon, 3 Mar 2008 10:16:04 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m23IFnW7020096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2008 12:15:54 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m23IFmHx008584; Mon, 3 Mar 2008 10:15:48 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m23IFi23008302; Mon, 3 Mar 2008 10:15:48 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Mar 2008 10:15:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 10:15:47 -0800 Message-ID: <08590A72DC26A54B85632FF97C2C22DA0616EAAD@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <20B895D1-8D9E-43DD-BE11-CBC99081C7CA@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPFv3 AF and MANET MDR code release Thread-Index: Ach7D5YWp6Xg4n4jT3+SFNC+gGYvNwADsiuw References: <44ED058B21DF294ABE394CABE5C1B52102658572@EXCH-CLUSTER-03.force10networks.com> <47C7F8B0.5060200@cisco.com> <20B895D1-8D9E-43DD-BE11-CBC99081C7CA@redback.com> From: "Spagnolo, Phillip A" To: "OSPF List" X-OriginalArrivalTime: 03 Mar 2008 18:15:47.0809 (UTC) FILETIME=[9AD2BD10:01C87D5A] Subject: [OSPF] OSPFv3 AF and MANET MDR code release 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 All, We are pleased to announce the release of Boeing's OSPFv3 Address Families and MANET MDR Quagga source code. The code has been upgraded to Quagga 0.99.9. OSPFv3 Address Families OSPFv3 MANET MDR The code can be found at . At the website, you will find * Documentation * Quagga Address Family patch * Quagga MANET MDR patch * Quagga MANET MDR GTNetS patch * GTNetS MANET MDR simulator Sincerely, Phillip A. Spagnolo Networked Systems Technology Boeing Phantom Works 425-373-2810 phillip.a.spagnolo@boeing.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From jra54449@fedex.com Thu Mar 6 19:00:25 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 C1EB93A691C for ; Thu, 6 Mar 2008 19:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=-2.562, BAYES_99=3.5, FRT_COCK=1.544, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_CCK=2.3, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADLTOBFU=0.68, SARE_OBFU_PART_OCK=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCx3LGPGO3hc for ; Thu, 6 Mar 2008 19:00:25 -0800 (PST) Received: from host222-110-dynamic.4-87-r.retail.telecomitalia.it (host222-110-dynamic.4-87-r.retail.telecomitalia.it [87.4.110.222]) by core3.amsl.com (Postfix) with SMTP id 085533A6A72 for ; Thu, 6 Mar 2008 19:00:20 -0800 (PST) Received: from 199.81.195.42 (HELO smtp.dmz.fedex.com) by megatron.ietf.org with ESMTP (ZYBQTFBRX IUOES) id mMIh1z-SgIhLd-rV for ospf-archive@megatron.ietf.org; Fri, 07 Mar 2008 04:00:07 +0100 Message-ID: <0d4c01c87fff$598bc7a0$de6e0457@Patsy> From: "Patsy Bergeron" To: "Natasha Lam" Subject: The person had beautiful eyes. Date: Fri, 07 Mar 2008 04:00:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_3402_0DB4_01C88007.BB502FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 This is a multi-part message in MIME format. ------=_NextPart_3402_0DB4_01C88007.BB502FA0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable All the chicks will dig your newfound size and girth to your c0ck! http://uhsuhsh.com/ ------=_NextPart_3402_0DB4_01C88007.BB502FA0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable ------=_NextPart_3402_0DB4_01C88007.BB502FA0-- From ospf-bounces@ietf.org Thu Mar 6 21:34: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 B8AE23A6A15; Thu, 6 Mar 2008 21:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.229 X-Spam-Level: X-Spam-Status: No, score=-95.229 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_12=2.46, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=1, RDNS_NONE=0.1, 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 By2h7AYKKpLd; Thu, 6 Mar 2008 21:34:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F2A3A6A7D; Thu, 6 Mar 2008 21:34:41 -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 090CA3A6A26 for ; Thu, 6 Mar 2008 21:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 hO5L2K1iX7CI for ; Thu, 6 Mar 2008 21:34:39 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by core3.amsl.com (Postfix) with ESMTP id A262B3A6A15 for ; Thu, 6 Mar 2008 21:34:22 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so302586gve.15 for ; Thu, 06 Mar 2008 21:34:10 -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:mime-version:content-type; bh=vhYYDKscIfjvxh4qGTuZSSFV4gkKL4mwW6mEL7cMX3g=; b=uaXVWbNIt6wIUAE+V8rNM9wspgEbSHX6V9s64qAEfSyVT3QoSd0PzNqtXj9ER2+/sW3VpRCHHsqYu8jJVqx2lElxWlSJBKImYvUzUrT+R97FzKbyW0MVq+7bbMg5w2mD+MF9UIlFyks34dxz/f/2OJNinUUE6D3LFKSuvU9WWDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=SlhOWiCgHVhLxSxDHyHp1tTwc6cg1vj9iUjZ3QqwH3QWtoFQ8xQuHOVIhenzM/12YdymhM73wVeh35p5k7rZN1CYkgt5JJOg/aEBH/doBibkqltW7iqMSJDgUNtil2iwyS+qiYd1H2MDLqfLHL07UfTt19pje3vki3gKwT5a0OE= Received: by 10.150.192.7 with SMTP id p7mr297840ybf.159.1204868049752; Thu, 06 Mar 2008 21:34:09 -0800 (PST) Received: by 10.150.178.2 with HTTP; Thu, 6 Mar 2008 21:34:09 -0800 (PST) Message-ID: Date: Fri, 7 Mar 2008 11:04:09 +0530 From: "Santosh P K" To: "ospf@ietf.org" MIME-Version: 1.0 Subject: [OSPF] OSPFv3 query 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="===============1849089928==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1849089928== Content-Type: multipart/alternative; boundary="----=_Part_11743_4459018.1204868049760" ------=_Part_11743_4459018.1204868049760 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline HI All, *Problem Description: *In the setup described above, a loopback address is configured on Router1 as *3002::1/64. *After configuring a virtual link between Router1 and Router2, the routes in Router2 show two different routes to the loopback address on Router1: *IA 3002::/64 (metric 20) and O 3002::1/128 (metric 10).* Why so? * * ------=_Part_11743_4459018.1204868049760 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
HI All,
 
Problem Description: In the setup described above, a loopback address is configured on Router1 as 3002::1/64. After configuring a virtual link between Router1 and Router2, the routes in Router2 show two different routes to the loopback address on Router1: IA 3002::/64 (metric 20) and O  3002::1/128 (metric 10). Why so?

 

------=_Part_11743_4459018.1204868049760-- --===============1849089928== 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 --===============1849089928==-- From ospf-bounces@ietf.org Thu Mar 6 23:38:06 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 5AAAB28C9A5; Thu, 6 Mar 2008 23:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.785 X-Spam-Level: X-Spam-Status: No, score=-99.785 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 tozsRra1MsEi; Thu, 6 Mar 2008 23:38:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4DB28C811; Thu, 6 Mar 2008 23:38:04 -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 938243A6920; Thu, 6 Mar 2008 23:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Bhe6muKIIoa4; Thu, 6 Mar 2008 23:38:02 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 1B4133A6E29; Thu, 6 Mar 2008 23:38:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k1KWjyu4yiohkM3uF9gS51hYFFjz/PsX2RfJZ2oUGV0Hnzfc4d9hmkWTXCPnSgy7; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.113.33] (helo=JoanPC) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JXX9G-00029f-Ga; Fri, 07 Mar 2008 02:37:47 -0500 Message-ID: <036501c88026$222ee3b0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Romascanu, Dan \(Dan\)" , "Acee Lindem" , , "MIB Doctors \(E-mail\)" References: <5F11B931-FB95-46B4-ABA4-649DFD3C4D00@cisco.com> <00524E68-9200-4DF7-A0F8-059CC1C8922F@redback.com> Date: Fri, 7 Mar 2008 02:37:44 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26541656132f2d019a4a5bdf009ef2b61d87387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.113.33 Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Folks, First is the output from the MIB tools. Followed by some General Comments, and then followed by fairly specific comments/questions on the MIB. Thanks, Joan SMICNG results: ---------------- E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax specified E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" must be defined with syntax that includes a range E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" must be defined with syntax that includes a range E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" must be defined with syntax that includes a range E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" must be defined with syntax that includes a range smilint ------------ severity level requested 6 line severity problem -------------------------- 2844 5 warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object (Please see comments below wrt Notifications) ID NITS (== 1 warning) -------- == The copyright year in the IETF Trust Copyright Line does not match the current year General Comments ----------------- 1) Need to have a read-only conformance. 2) I would like to understand the use of the single DiscontinuityTime object for all the counters in the MIB. My thoughts are that having a few more discontinuity objects (specifically in tables) would be more beneficial, so please give me some feedback on this, so I can understand why only one Discontinuity object is used. 3) Throttling of notifications and Polling Event Counters. I think more details of this need to be in the MIB itself. Please expand some of these DESCRIPTIONS. 4) Please note that many of my comments apply to the entire MIB, although I only commented on the first few objects. Please be sure to check the entire MIB for an issue. For example, please rename any RowStatus object with xxxRowStatus, please spell out Interval, etc. 5) The MIB did not extract using mstrip (MIB tool). If possible, could this be fixed? Comments in Order of the document ---------------------------------- 1) (NIT) Header should say: Proposed Status: Standards Track 2) (NIT) Expiration date has incorrect year. *) (NIT) please be consistent with using RFCXXX vs. MIB tree assignment, so for example DESCRIPTION "The MIB module for OSPF version 3. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." REVISION "200709171200Z" DESCRIPTION -- RFC Editor assigns RFC XXXX "Initial version, published as RFC XXXX" ::= { mib-2 YYY } -- to be assigned by IANA *)Ospfv3UpToRefreshIntervalTc *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC *) Could DISPLAY-HINT "d" be used instead? *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) *) Please add a reference *) Ospfv3DeadIntRangeTc *) Please spell out Interval and change Tc to TC, i.e. Ospfv3DeadIntervalRangeTC *) Could DISPLAY-HINT "d" be used instead? *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) *) Please add a reference *) Ospfv3RouterIdTC *) Please use TC, Ospfv3RouterIdTC *) Could DISPLAY-HINT "d" be used instead? *) Please add a reference *) Ospfv3AreaIdTc *) Please use TC, Ospfv3AreaIdTC *) Could DISPLAY-HINT "d" be used instead? *) Please add a reference *) Ospfv3IfInstIdTc *) Please Tc to TC, i.e. Ospfv3IfInstIdTC *) Could DISPLAY-HINT "d" be used instead? *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) *) Please add a reference *) ospfv3RouterId Isn't this a 32-bit unsigned integer? Please add REFERENCE clause. *) ospfv3AreaBdrRtrStatus Please indicate the value of the flag when the router is an area border router. (i.e. when the value of this object is true(1)...) *) ospfv3AsScopeLsaCksumSum *) should be Unsigned32 *) ospfv3DemandExtensions Same comment as with the previous object that has SYNTAX of TruthValue, please specify, when this object has the value of true(1), then the router supports demand circuits... *) ospfv3ReferenceBandwidth -Please add UNITS -Please add DEFVAL - Please add REFERENCE *) ospfv3RestartSupport -Is there a value which could be considered a DEFVAL for this object? (In general, please review all the read-write objects and add DEFVALs if appropriate). *) ospfv3RestartInterval -Is there a value which could be considered a DEFVAL for this object? *) ospfv3RestartStrictLsaChecking Please indicate what true(1) means in the DESCRIPTION (Please do this for all objects which contain a TruthValue) *) ospfv3RestartExitRc What does the Rc stand for, could this be spelled out? Are any additional objects needed to tell when the value of this object changed? *) ospfv3NotificationEnable Why is this object needed? Or,in other words, why can't RFC3413 be used. *) ospfv3StubRouterAdvertisement Need to add DEFVAL Please add a REFERENCE *) ospfv3AreaTable - This table has a combination of both objects to configure areas and statistics for areas. Could this be devided into 2 tables one for configuring and one for status/statics? Additionally, if is not clear to me what happens when an attached area is established and then the configuration changes? Can the configurable objects be changed? Also, the counters in this table refer to ospfv3DiscontinuityTime but if the OSPFv3 routing process starts-up, then my understanding is that these counters might be affected (specifically, ospfv3AreaNssTranslatorEvents), so I think another discontinuityTime object is needed...please comment. *) ospfv3AreaId Isn't this unsigned? *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this table may have a DEFVAL clause of zero (this is mentioned in the DESCRIPTION clauses). *) ospfv3AreaScopeLsaCksumSum Should this be Unsigned32? *) ospfv3AreaStatus Please rename to ospfv3AreaRowStatus *) ospfv3AreaStubMetric Is there a DEFVAL for this object? *) ospfv3AreaNssaTranslatorStabInt Please use entire word Interval *) ospfv3AsLsdbSequence Should this have a range? *) ospfv3AreaLsdbSequence (same question, is there a range for this?) *) ospfv3AreaLsdbAge Unsigned32 and a range? What is the value if the DoNotAge Bit is set? *) ospfv3AreaLsdbChecksum Should this be unsigned32? *) ospfv3AreaLsdbTypeKnown Please indicate what true(1) means in the DESCRIPTION *) ospfv3LinkLsdbSequence Same comment as with the other Sequence numbers, should this have a range? Additionally, should these sequence numbers have a common TC? *)ospfv3LinkLsdbAge same comments and questions as with the "Age" object in the prior table? *) ospfv3LinkLsdbChecksum Unsigned32? *) ospfv3HostTable Need to have a storageType object added to this table. *) ospfv3HostStatus Please rename to ospfv3HostRowStatus Usually, this is the last in the list of objects. *)ospfv3IfTable Don't understand the REFERENCE here, please explain. Same comment as with the other table, there is mix of configuration and status/statistics in this one table. Could this be made into 2 tables? Also, the Counters in this table likely need their own discontinuityTime object.... Can configurable objects change once the interface is established (for example, if the interface is pointToPoint?) *) ospfv3IfTransitDelay Don't understand the DESCRIPTION here. Could you please expand. Is there a REFERENCE that could be added? *) ospfv3IfStatus Please rename to ospfv3IfRowStatus *) ospfv3IfAdminStat Would an OperStatus object be beneficial in this table? *) ospfv3IfDemandNbrProbeRetxLimit Retx is used for Retransmission, elsewhere Retrans was used. Please be consistant. *) ospfv3VirtIfTable Don't understand the reference here. If this is an IPv6/V3 specific table then why are you Refering to OSPFv2? Is this correct? Additionally, could a OSPFv3 REFERENCE be added also? Same comments as with the other tables that have a mix of config and status/statistics objects. Please change RowStatus objects to have RowStatus at the end of their name. *) ospfv3NbrTable Same question as to how the Counters in this table can successfully use ospfv3DiscontinuityTime. In other words, if this table is specific to neighbors, then the counters are also, so there might be (at least it seems to me) a case where an entry in this table is affected and neighbor counters suffer a discontinuity but the ospfv3DiscontinuityTime may not. Please comment. *) ospfv3NbrTable and ospfv3CfgNbrTable What is the relationship between these 2 tables? The indexing is different between the 2 tables and so I'm wondering what the relationship is between them. *) ospfv3AreaAggregateRouteTag Is this Unsigned32? Notifications ------------ In general the accessible-for-notify objects should probably be changed into read-only objects. Additionally, a timestamp should be associated with some of these. There is an assumption made that it is better to send out notifications rather than poll, but I'd rather give the operator the choice on that. Compliance Statements ------------------------- * Need a Read-only compliance statement. It is missing. --- _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 7 01:55:33 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 11A3B28C279; Fri, 7 Mar 2008 01:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.158 X-Spam-Level: X-Spam-Status: No, score=-100.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, 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 Cum0S-kBs68y; Fri, 7 Mar 2008 01:55:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A95A3A6D91; Fri, 7 Mar 2008 01:55: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 AF9CD3A6A2A for ; Fri, 7 Mar 2008 01:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 ate2rrHL5sZ9 for ; Fri, 7 Mar 2008 01:55:30 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 8F9703A6D91 for ; Fri, 7 Mar 2008 01:55:29 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so391464fgg.41 for ; Fri, 07 Mar 2008 01:55:18 -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:mime-version:content-type; bh=puojJkkhBdyqLOSG4fcsoTQE5i1PeOUie7kfFXg1YiY=; b=ML2RGjXvf0LFg536bdyE0dshMN3ygkTdvm5oimD/ikq9X/o7DzI10KWTlIYqsOJ0IC9S9+wckXI4Fy8o96VYZpVM2AQXdQu+Dgam7BVGifRS3GvrZseGGBsM5k+tmymw7HMsiFvQsn0ETFu+kJCRfSrYYhmkVdqqWKKHekI8E6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=NeaEuIgphqzSkwlzFf1h6FHVLIcBoGQm1HF88JYaEw4WRdczccO6RN6WnQ4udkvaTO76thFKf0qdMbrjPp9al99zH3WSZ4Lmq26z8w3UIZzxtdC+BAnLHP2LcK6A3976+PNdPvFMWMsSiO/rfJnT7nTXGKCAf+Kmz/Z4CUe67xc= Received: by 10.86.72.15 with SMTP id u15mr1246573fga.21.1204883718322; Fri, 07 Mar 2008 01:55:18 -0800 (PST) Received: by 10.86.29.1 with HTTP; Fri, 7 Mar 2008 01:55:18 -0800 (PST) Message-ID: <6b63093f0803070155qb3cb218tcb4f1d44d1a495ec@mail.gmail.com> Date: Fri, 7 Mar 2008 15:25:18 +0530 From: "Lokesh Jain" To: ospf@ietf.org MIME-Version: 1.0 Subject: [OSPF] Query related to RFC 4577 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="===============2078896774==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============2078896774== Content-Type: multipart/alternative; boundary="----=_Part_1907_6349336.1204883718289" ------=_Part_1907_6349336.1204883718289 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, In RFC 4577, page number 3 it is written that: "If a customer is transitioning his network from a traditional OSPF backbone to the VPN service described in [VPN], the use of OSPF on the PE-CE link eases the transitional issues." Please anyone explain this in more details or give a pointer to the source where I can find the answer to my question. -- ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take ------=_Part_1907_6349336.1204883718289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

In RFC 4577, page number 3 it is written that:

"If a customer is transitioning his network from a traditional
OSPF backbone to the VPN service described in [VPN], the use of
OSPF on the PE-CE link eases the transitional issues."

Please anyone explain this in more details or give a pointer to the source where I can find the answer to my question.

--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take ------=_Part_1907_6349336.1204883718289-- --===============2078896774== 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 --===============2078896774==-- From ospf-bounces@ietf.org Fri Mar 7 02:16: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 BAA5B3A67F1; Fri, 7 Mar 2008 02:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.653 X-Spam-Level: X-Spam-Status: No, score=-99.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, 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 Hw1vp4U-SQJj; Fri, 7 Mar 2008 02:16:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF743A688F; Fri, 7 Mar 2008 02:16: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 DF2D93A688F for ; Fri, 7 Mar 2008 02:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 W8F1rrOGkhoG for ; Fri, 7 Mar 2008 02:16:37 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id DD06B3A6A5B for ; Fri, 7 Mar 2008 02:16:36 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so397833fgg.41 for ; Fri, 07 Mar 2008 02:16: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:mime-version:content-type; bh=8w+ep2SanGXrCSSDzAt4U7SUYvXWN+W5PwfmOfUkSJE=; b=Znpl9MR9ZY1JQ5GdEUh6iUibWePMJsmH4Yu2IDj0QKwWr76D1Rn8WPTXQ0NQKxnCnI6tMRZ3Kli9o1I1VW57xWNCUfnVOSSeMy7gh6oRU4qlBbjLa3PGm39aEFB7JJLYw9WljcHY8M2Zqf6gFOOSmVeSBwwhC0RcD1fWWNQBdzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ey2EZgJTFpGs6qIJh6BehW/GV6AoWWIcgq+iO63iA4FfjAmQ0gdlW23jvwKmfX87CtqC4i1BQP40uk1/wZdl9MvN01C3A2AeM8aXRMmS8QYXaKr/T8/lIqCDww7CL5SDHg71V8ig5FQlo/1jUXdWKg0pOJsCj0x97gAw1qNliis= Received: by 10.86.97.7 with SMTP id u7mr1255909fgb.39.1204884985632; Fri, 07 Mar 2008 02:16:25 -0800 (PST) Received: by 10.86.29.1 with HTTP; Fri, 7 Mar 2008 02:16:25 -0800 (PST) Message-ID: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com> Date: Fri, 7 Mar 2008 15:46:25 +0530 From: "Lokesh Jain" To: ospf@ietf.org MIME-Version: 1.0 Subject: [OSPF] RFC 4577 Query 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="===============0043411928==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0043411928== Content-Type: multipart/alternative; boundary="----=_Part_1964_24315673.1204884985622" ------=_Part_1964_24315673.1204884985622 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, In RFC 4577 it states that earlier PE-CE link used BGP but to provide certain advantages to customer, OSPF would be a better choice between PE-CE link. But to do that we have to modify BGP /OSPF interaction so that routes are distributed as inter-area routes and not as AS-External routes. My doubt is: In earlier scenario, CE would be running an instance of BGP and some other IGP, say OSPF. In that case also the routes distributed in a customer VPN site would be AS-External routes and not inter-area routes. How was that handled in previous case? Or is it the just the case of moving BGP/OSPF interaction from CE to PE? Please guide me regarding this. I must be missing on some point here. -- ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take ------=_Part_1964_24315673.1204884985622 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

In RFC 4577 it states that earlier PE-CE link used BGP but to provide certain advantages to customer, OSPF would be a better choice between PE-CE link.
But to do that we have to modify BGP /OSPF interaction so that routes are distributed as inter-area routes and not as AS-External routes.

My doubt is:

In earlier scenario, CE would be running an instance of BGP and some other IGP, say OSPF. In that case also the routes distributed in a customer VPN site would be AS-External routes and not inter-area routes. How was that handled in previous case? Or is it the just the case of moving BGP/OSPF interaction from CE to PE?

Please guide me regarding this. I must be missing on some point here.

--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take ------=_Part_1964_24315673.1204884985622-- --===============0043411928== 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 --===============0043411928==-- From ospf-bounces@ietf.org Fri Mar 7 06:53:22 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 0236928C441; Fri, 7 Mar 2008 06:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 XQXja39kE27K; Fri, 7 Mar 2008 06:53:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063033A6D48; Fri, 7 Mar 2008 06:53:21 -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 2AAD83A6D48 for ; Fri, 7 Mar 2008 06:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 596x+xN+FN6l for ; Fri, 7 Mar 2008 06:53:18 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 571E23A6B46 for ; Fri, 7 Mar 2008 06:53:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E09C67F48CE; Fri, 7 Mar 2008 06:53: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 26945-05; Fri, 7 Mar 2008 06:53:07 -0800 (PST) Received: from [ZK?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 719037F48CD; Fri, 7 Mar 2008 06:53:07 -0800 (PST) In-Reply-To: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com> References: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <24EF29F9-5B7B-41A7-B5C1-5215750DF01B@redback.com> From: Acee Lindem Date: Fri, 7 Mar 2008 09:53:06 -0500 To: "Lokesh Jain" X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] RFC 4577 Query 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 Lokesh, On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote: > Hi All, > > In RFC 4577 it states that earlier PE-CE link used BGP but to > provide certain advantages to customer, OSPF would be a better > choice between PE-CE link. > But to do that we have to modify BGP /OSPF interaction so that > routes are distributed as inter-area routes and not as AS-External > routes. > > My doubt is: > > In earlier scenario, CE would be running an instance of BGP and > some other IGP, say OSPF. In that case also the routes distributed > in a customer VPN site would be AS-External routes and not inter- > area routes. How was that handled in previous case? Or is it the > just the case of moving BGP/OSPF interaction from CE to PE? > > Please guide me regarding this. I must be missing on some point here. The point is for an ISP to provide a transparent Layer 3 VPN service. If the CE is forced to handle all the complexity of the BGP/IGP interaction, this is hardly transparent. RFC 4577 mostly succeeds in this goal and is widely deployed. Hope this Helps, Acee > > > -- > ~~~~~~~~~~~~~ > Thanks & Regards, > ~~~~~~~~~~~~~ > Lokesh Jain > Senior Software Engineer, > Samsung India Software Operations Pvt. Ltd., > Bagmane Tech Park, C V Raman Nagar, > Bangalore. > Mob: 9880611348 > ----------------------------------------------------- > You always miss 100% of the chances u don't take > _______________________________________________ > 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 Fri Mar 7 07:35:17 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 6DDAC28C614; Fri, 7 Mar 2008 07:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.007 X-Spam-Level: X-Spam-Status: No, score=-100.007 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 t6pmsCWwTSds; Fri, 7 Mar 2008 07:35:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24393A69CC; Fri, 7 Mar 2008 07:35: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 BE4313A6F37; Fri, 7 Mar 2008 07:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Q90h0tFWtqnU; Fri, 7 Mar 2008 07:35:13 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 18FC23A69CC; Fri, 7 Mar 2008 07:35:13 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m27FYvD13604; Fri, 7 Mar 2008 15:34:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 10:34:53 -0500 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501413B24A8D@zrtphxm1.corp.nortel.com> In-Reply-To: <036501c88026$222ee3b0$6601a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt thread-index: AciAJin3P6jmTknHQDqTmbmbxcevHwAQk+NA References: <036501c88026$222ee3b0$6601a8c0@JoanPC> From: "Daniel Joyal" To: "Joan Cucchiara" , "Romascanu, Dan (Dan)" , "Acee Lindem" , , "MIB Doctors (E-mail)" Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Joan, Thanks for the prompt and very thorough review. We will get to work addressing the comments. Regards, -Dan > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, March 07, 2008 2:38 AM > To: Romascanu, Dan (Dan); Acee Lindem; ospf@ietf.org; MIB > Doctors (E-mail) > Cc: Ronald Bonica; Abhay Roy; Ross Callon; Vishwas Manral; > Joyal, Daniel (BL60:SF23); Bert Wijnen; David Ward > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > Hi Folks, > > First is the output from the MIB tools. > Followed by some General Comments, and then followed by > fairly specific comments/questions on the MIB. > > Thanks, > Joan > > > SMICNG results: > ---------------- > > E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" > in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax > specified > > E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" > must be defined with syntax that includes a range > > > smilint > ------------ > severity level requested 6 > > line severity problem > -------------------------- > > 2844 5 warning: `InetAddress' object should have an > accompanied preceding `InetAdressType' object > (Please see comments below wrt Notifications) > > > > ID NITS (== 1 warning) > -------- > > == The copyright year in the IETF Trust Copyright Line does > not match the > current year > > > > > General Comments > ----------------- > > 1) Need to have a read-only conformance. > > 2) I would like to understand the use of the single > DiscontinuityTime object for all the counters in the MIB. My > thoughts are that having a few more discontinuity objects > (specifically in tables) would be more beneficial, so please > give me some feedback on this, so I can understand why only > one Discontinuity object is used. > > 3) Throttling of notifications and Polling Event Counters. > I think more details of this need to be in the MIB itself. > Please expand some of these DESCRIPTIONS. > > 4) Please note that many of my comments apply to the entire > MIB, although I only commented on the first few objects. > Please be sure to check the entire MIB for an issue. For > example, please rename any RowStatus object with > xxxRowStatus, please spell out Interval, etc. > > 5) The MIB did not extract using mstrip (MIB tool). > If possible, could this be fixed? > > > Comments in Order of the document > ---------------------------------- > > 1) (NIT) Header should say: > Proposed Status: Standards Track > > > 2) (NIT) Expiration date has incorrect year. > > > *) (NIT) please be consistent with using RFCXXX vs. MIB tree > assignment, so for example > > DESCRIPTION > "The MIB module for OSPF version 3. > > Copyright (C) The IETF Trust (2007). > This version of this MIB module is part of > RFC XXXX; see the RFC itself for full legal > notices." > > REVISION "200709171200Z" > DESCRIPTION -- RFC Editor assigns RFC XXXX > "Initial version, published as RFC XXXX" > > ::= { mib-2 YYY } -- to be assigned by IANA > > > > > *)Ospfv3UpToRefreshIntervalTc > > *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3DeadIntRangeTc > *) Please spell out Interval and change Tc to TC, > i.e. Ospfv3DeadIntervalRangeTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3RouterIdTC > > *) Please use TC, Ospfv3RouterIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Please add a reference > > *) Ospfv3AreaIdTc > > *) Please use TC, Ospfv3AreaIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > > *) Please add a reference > > > *) Ospfv3IfInstIdTc > > *) Please Tc to TC, i.e. Ospfv3IfInstIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > > *) ospfv3RouterId > > Isn't this a 32-bit unsigned integer? > Please add REFERENCE clause. > > > *) ospfv3AreaBdrRtrStatus > > Please indicate the value of the flag > when the router is an area border router. > (i.e. when the value of this object is true(1)...) > > *) ospfv3AsScopeLsaCksumSum > > *) should be Unsigned32 > > > *) ospfv3DemandExtensions > > Same comment as with the previous object that has SYNTAX of > TruthValue, please specify, when this object has the value of > true(1), then the router supports demand circuits... > > *) ospfv3ReferenceBandwidth > > -Please add UNITS > -Please add DEFVAL > - Please add REFERENCE > > > *) ospfv3RestartSupport > > -Is there a value which could be considered a DEFVAL for this object? > (In general, please review all the read-write objects and add > DEFVALs if appropriate). > > *) ospfv3RestartInterval > -Is there a value which could be considered a DEFVAL for this object? > > > *) ospfv3RestartStrictLsaChecking > > Please indicate what true(1) means in the DESCRIPTION (Please > do this for all objects which contain a > TruthValue) > > *) ospfv3RestartExitRc > > What does the Rc stand for, could this be spelled out? > > Are any additional objects needed to tell when the value of > this object changed? > > *) ospfv3NotificationEnable > > Why is this object needed? Or,in other words, why can't > RFC3413 be used. > > *) ospfv3StubRouterAdvertisement > > Need to add DEFVAL > Please add a REFERENCE > > *) ospfv3AreaTable > > - This table has a combination of both objects to configure > areas and statistics for areas. Could this be devided into > 2 tables one for configuring and one for status/statics? > > Additionally, if is not clear to me what happens when an > attached area is established and then the configuration > changes? Can the configurable objects be changed? > > Also, the counters in this table refer to > ospfv3DiscontinuityTime but if the OSPFv3 routing process > starts-up, then my understanding is that these counters might > be affected (specifically, ospfv3AreaNssTranslatorEvents), so > I think another discontinuityTime object is needed...please comment. > > > *) ospfv3AreaId > > Isn't this unsigned? > > > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > table may have a DEFVAL clause of zero (this is mentioned in > the DESCRIPTION clauses). > > *) ospfv3AreaScopeLsaCksumSum > > Should this be Unsigned32? > > > *) ospfv3AreaStatus > > Please rename to ospfv3AreaRowStatus > > *) ospfv3AreaStubMetric > > Is there a DEFVAL for this object? > > > *) ospfv3AreaNssaTranslatorStabInt > > Please use entire word Interval > > > > *) ospfv3AsLsdbSequence > > Should this have a range? > > *) ospfv3AreaLsdbSequence > > (same question, is there a range for this?) > > *) ospfv3AreaLsdbAge > > Unsigned32 and a range? > > What is the value if the DoNotAge Bit is set? > > *) ospfv3AreaLsdbChecksum > > Should this be unsigned32? > > > *) ospfv3AreaLsdbTypeKnown > > Please indicate what true(1) means in the > DESCRIPTION > > *) ospfv3LinkLsdbSequence > > Same comment as with the other Sequence numbers, > should this have a range? Additionally, should these > sequence numbers have a common TC? > > *)ospfv3LinkLsdbAge > > same comments and questions > as with the "Age" object in the prior table? > > *) ospfv3LinkLsdbChecksum > > Unsigned32? > > > *) ospfv3HostTable > > Need to have a storageType object added to this table. > > > > > > *) ospfv3HostStatus > > Please rename to ospfv3HostRowStatus > Usually, this is the last in the list of objects. > > *)ospfv3IfTable > > Don't understand the REFERENCE here, please explain. > > > Same comment as with the other table, there is mix of > configuration and status/statistics in this one table. > Could this be made into 2 tables? > > Also, the Counters in this table > likely need their own discontinuityTime object.... > > Can configurable objects change once the interface > is established (for example, if the interface is pointToPoint?) > > > > > *) ospfv3IfTransitDelay > > Don't understand the DESCRIPTION here. Could you > please expand. > > Is there a REFERENCE that could be added? > > *) ospfv3IfStatus > > Please rename to ospfv3IfRowStatus > > *) ospfv3IfAdminStat > > Would an OperStatus object be beneficial in this > table? > > *) ospfv3IfDemandNbrProbeRetxLimit > > Retx is used for Retransmission, elsewhere Retrans > was used. Please be consistant. > > *) ospfv3VirtIfTable > > Don't understand the reference here. If this is > an IPv6/V3 specific table then why are you > Refering to OSPFv2? Is this correct? Additionally, > could a OSPFv3 REFERENCE be added also? > > Same comments as with the other tables that have > a mix of config and status/statistics objects. > > Please change RowStatus objects to have RowStatus > at the end of their name. > > *) ospfv3NbrTable > > Same question as to how the Counters in this table > can successfully use ospfv3DiscontinuityTime. In other > words, if this table is specific to neighbors, then > the counters are also, so there might be (at least it > seems to me) a case where an entry in this table is > affected and neighbor counters suffer a discontinuity > but the ospfv3DiscontinuityTime may not. Please comment. > > > *) ospfv3NbrTable and ospfv3CfgNbrTable > > What is the relationship between these 2 tables? > The indexing is different between the 2 tables and so > I'm wondering what the relationship is between them. > > > > *) ospfv3AreaAggregateRouteTag > > Is this Unsigned32? > > > Notifications > ------------ > > In general the accessible-for-notify objects should probably be > changed into read-only objects. Additionally, a timestamp should > be associated with some of these. There is an assumption made that > it is better to send out notifications rather than poll, but I'd > rather give the operator the choice on that. > > > > > > > > Compliance Statements > ------------------------- > > * Need a Read-only compliance statement. > It is missing. > > --- > > > > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 7 09:37:28 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 1F98328C2E1; Fri, 7 Mar 2008 09:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.533 X-Spam-Level: X-Spam-Status: No, score=-98.533 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 h1EtMyeJE09X; Fri, 7 Mar 2008 09:37:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715EF3A6D8A; Fri, 7 Mar 2008 09:37:26 -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 AC6793A6AAF; Fri, 7 Mar 2008 09:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 zpb2k+SyL728; Fri, 7 Mar 2008 09:37:23 -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 14D443A68D7; Fri, 7 Mar 2008 09:37:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qaypUbXRFmKEC3weqt2VmfP8IFQAQxK1Xz6ZXPisvX0J+C5nWxFV1IuPFbwAboMT; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.113.33] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JXgVJ-0002RX-5c; Fri, 07 Mar 2008 12:37:10 -0500 Message-ID: <039601c88079$dd9d97b0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Joan Cucchiara" , "Romascanu, Dan \(Dan\)" , "Acee Lindem" , , "MIB Doctors \(E-mail\)" Date: Fri, 7 Mar 2008 12:37:07 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654c56187c8ea7a5b6fe64d467f9c3c77c73ca473d225a0f487350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.113.33 Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hello, I do also have one other question. There seems to be quite a bit of overlap between RFC4750 (OSPFv2 MIB) and this draft. While I understand that there are obvious differences between IPv4 and IPv6 addresses, and also some differences in OSPFv2 vs. OSPFv3, I still see many of the same MIB objects in the 2 MIB Modules, did the authors consider using OSPFv2 MIB and doing AUGMENTS for OSPFv3? Please give me some background/history on why a completely separate MIB Module was done for OSPFv3. Thank you, Joan ----- Original Message ----- From: "Joan Cucchiara" To: "Romascanu, Dan (Dan)" ; "Acee Lindem" ; ; "MIB Doctors (E-mail)" Cc: "Ronald Bonica" ; "Abhay Roy" ; "Ross Callon" ; "Vishwas Manral" ; "Dan Joyal" ; "Bert Wijnen" ; "David Ward" Sent: Friday, March 07, 2008 2:37 AM Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > Hi Folks, > > First is the output from the MIB tools. > Followed by some General Comments, and then followed by > fairly specific comments/questions on the MIB. > > Thanks, > Joan > > > SMICNG results: > ---------------- > > E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" > in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax specified > > E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" > must be defined with syntax that includes a range > > > smilint > ------------ > severity level requested 6 > > line severity problem > -------------------------- > > 2844 5 warning: `InetAddress' object should have an > accompanied preceding `InetAdressType' object > (Please see comments below wrt Notifications) > > > > ID NITS (== 1 warning) > -------- > > == The copyright year in the IETF Trust Copyright Line does not match the > current year > > > > > General Comments > ----------------- > > 1) Need to have a read-only conformance. > > 2) I would like to understand the use of the single > DiscontinuityTime object for all the counters in the > MIB. My thoughts are that having a few more discontinuity > objects (specifically in tables) would be more beneficial, > so please give me some feedback on this, so I can understand > why only one Discontinuity object is used. > > 3) Throttling of notifications and Polling Event Counters. > I think more details of this need to be in the MIB itself. > Please expand some of these DESCRIPTIONS. > > 4) Please note that many of my comments apply to the entire MIB, although > I only commented on the first few objects. Please be sure to check the > entire MIB for an issue. For example, please rename any RowStatus object > with xxxRowStatus, please spell out Interval, etc. > > 5) The MIB did not extract using mstrip (MIB tool). > If possible, could this be fixed? > > > Comments in Order of the document > ---------------------------------- > > 1) (NIT) Header should say: > Proposed Status: Standards Track > > > 2) (NIT) Expiration date has incorrect year. > > > *) (NIT) please be consistent with using > RFCXXX vs. MIB tree assignment, so for example > > DESCRIPTION > "The MIB module for OSPF version 3. > > Copyright (C) The IETF Trust (2007). > This version of this MIB module is part of > RFC XXXX; see the RFC itself for full legal > notices." > > REVISION "200709171200Z" > DESCRIPTION -- RFC Editor assigns RFC XXXX > "Initial version, published as RFC XXXX" > > ::= { mib-2 YYY } -- to be assigned by IANA > > > > > *)Ospfv3UpToRefreshIntervalTc > > *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3DeadIntRangeTc > *) Please spell out Interval and change Tc to TC, > i.e. Ospfv3DeadIntervalRangeTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3RouterIdTC > > *) Please use TC, Ospfv3RouterIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Please add a reference > > *) Ospfv3AreaIdTc > > *) Please use TC, Ospfv3AreaIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > > *) Please add a reference > > > *) Ospfv3IfInstIdTc > > *) Please Tc to TC, i.e. Ospfv3IfInstIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > > *) ospfv3RouterId > > Isn't this a 32-bit unsigned integer? > Please add REFERENCE clause. > > > *) ospfv3AreaBdrRtrStatus > > Please indicate the value of the flag > when the router is an area border router. > (i.e. when the value of this object is true(1)...) > > *) ospfv3AsScopeLsaCksumSum > > *) should be Unsigned32 > > > *) ospfv3DemandExtensions > > Same comment as with the previous object that has SYNTAX of TruthValue, > please specify, when this object has the value of true(1), then > the router supports demand circuits... > > *) ospfv3ReferenceBandwidth > > -Please add UNITS > -Please add DEFVAL > - Please add REFERENCE > > > *) ospfv3RestartSupport > > -Is there a value which could be considered a DEFVAL for > this object? > (In general, please review all the read-write objects > and add DEFVALs if appropriate). > > *) ospfv3RestartInterval > -Is there a value which could be considered a DEFVAL for > this object? > > > *) ospfv3RestartStrictLsaChecking > > Please indicate what true(1) means in the DESCRIPTION > (Please do this for all objects which contain a > TruthValue) > > *) ospfv3RestartExitRc > > What does the Rc stand for, could this be spelled out? > > Are any additional objects needed to tell when the > value of this object changed? > > *) ospfv3NotificationEnable > > Why is this object needed? Or,in other words, why > can't RFC3413 be used. > > *) ospfv3StubRouterAdvertisement > > Need to add DEFVAL > Please add a REFERENCE > > *) ospfv3AreaTable > > - This table has a combination of both objects to configure > areas and statistics for areas. Could this be devided into > 2 tables one for configuring and one for status/statics? > > Additionally, if is not clear to me what happens when an attached > area is established and then the configuration changes? Can > the configurable objects be changed? > > Also, the counters in this table refer to ospfv3DiscontinuityTime > but if the OSPFv3 routing process starts-up, then my understanding > is that these counters might be affected (specifically, > ospfv3AreaNssTranslatorEvents), > so I think another discontinuityTime object is needed...please comment. > > > *) ospfv3AreaId > > Isn't this unsigned? > > > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > table may have a DEFVAL clause of zero (this is mentioned in > the DESCRIPTION clauses). > > *) ospfv3AreaScopeLsaCksumSum > > Should this be Unsigned32? > > > *) ospfv3AreaStatus > > Please rename to ospfv3AreaRowStatus > > *) ospfv3AreaStubMetric > > Is there a DEFVAL for this object? > > > *) ospfv3AreaNssaTranslatorStabInt > > Please use entire word Interval > > > > *) ospfv3AsLsdbSequence > > Should this have a range? > > *) ospfv3AreaLsdbSequence > > (same question, is there a range for this?) > > *) ospfv3AreaLsdbAge > > Unsigned32 and a range? > > What is the value if the DoNotAge Bit is set? > > *) ospfv3AreaLsdbChecksum > > Should this be unsigned32? > > > *) ospfv3AreaLsdbTypeKnown > > Please indicate what true(1) means in the > DESCRIPTION > > *) ospfv3LinkLsdbSequence > > Same comment as with the other Sequence numbers, > should this have a range? Additionally, should these > sequence numbers have a common TC? > > *)ospfv3LinkLsdbAge > > same comments and questions > as with the "Age" object in the prior table? > > *) ospfv3LinkLsdbChecksum > > Unsigned32? > > > *) ospfv3HostTable > > Need to have a storageType object added to this table. > > > > > > *) ospfv3HostStatus > > Please rename to ospfv3HostRowStatus > Usually, this is the last in the list of objects. > > *)ospfv3IfTable > > Don't understand the REFERENCE here, please explain. > > > Same comment as with the other table, there is mix of > configuration and status/statistics in this one table. > Could this be made into 2 tables? > > Also, the Counters in this table > likely need their own discontinuityTime object.... > > Can configurable objects change once the interface > is established (for example, if the interface is pointToPoint?) > > > > > *) ospfv3IfTransitDelay > > Don't understand the DESCRIPTION here. Could you > please expand. > > Is there a REFERENCE that could be added? > > *) ospfv3IfStatus > > Please rename to ospfv3IfRowStatus > > *) ospfv3IfAdminStat > > Would an OperStatus object be beneficial in this > table? > > *) ospfv3IfDemandNbrProbeRetxLimit > > Retx is used for Retransmission, elsewhere Retrans > was used. Please be consistant. > > *) ospfv3VirtIfTable > > Don't understand the reference here. If this is > an IPv6/V3 specific table then why are you > Refering to OSPFv2? Is this correct? Additionally, > could a OSPFv3 REFERENCE be added also? > > Same comments as with the other tables that have > a mix of config and status/statistics objects. > > Please change RowStatus objects to have RowStatus > at the end of their name. > > *) ospfv3NbrTable > > Same question as to how the Counters in this table > can successfully use ospfv3DiscontinuityTime. In other > words, if this table is specific to neighbors, then > the counters are also, so there might be (at least it > seems to me) a case where an entry in this table is > affected and neighbor counters suffer a discontinuity > but the ospfv3DiscontinuityTime may not. Please comment. > > > *) ospfv3NbrTable and ospfv3CfgNbrTable > > What is the relationship between these 2 tables? > The indexing is different between the 2 tables and so > I'm wondering what the relationship is between them. > > > > *) ospfv3AreaAggregateRouteTag > > Is this Unsigned32? > > > Notifications > ------------ > > In general the accessible-for-notify objects should probably be > changed into read-only objects. Additionally, a timestamp should > be associated with some of these. There is an assumption made that > it is better to send out notifications rather than poll, but I'd > rather give the operator the choice on that. > > > > > > > > Compliance Statements > ------------------------- > > * Need a Read-only compliance statement. > It is missing. > > --- > > > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 7 09:40:23 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 15D8828C2E1; Fri, 7 Mar 2008 09:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-3.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 9B50HJXfcdqT; Fri, 7 Mar 2008 09:40:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA983A68A5; Fri, 7 Mar 2008 09:40:21 -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 7D14C3A68A5; Fri, 7 Mar 2008 09:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 FGrBmHHo4CAK; Fri, 7 Mar 2008 09:40:18 -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 F29463A683F; Fri, 7 Mar 2008 09:40:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,463,1199682000"; d="scan'208";a="829436" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2008 12:40:06 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m27He6qA005458; Fri, 7 Mar 2008 12:40:06 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m27Hdgjl014891; Fri, 7 Mar 2008 17:40:01 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 12:39:53 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 12:39:53 -0500 In-Reply-To: <039601c88079$dd9d97b0$6601a8c0@JoanPC> References: <039601c88079$dd9d97b0$6601a8c0@JoanPC> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: David Ward Date: Fri, 7 Mar 2008 11:39:49 -0600 To: "Joan Cucchiara" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 07 Mar 2008 17:39:53.0415 (UTC) FILETIME=[405B4D70:01C8807A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12307; t=1204911606; x=1205775606; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20MIB=20Dr.=20Review=20of=20draft-ietf-os pf-ospfv3-mib-12.txt |Sender:=20 |To:=20=22Joan=20Cucchiara=22=20; bh=ln/mLhBzn4clvrcHTUgEJmki7EWM/zqZFOg/bIT7n2k=; b=BI/nB4oUhsljHUMQ/DUdtXzoqHiZBvCguHcTrQLGUwFSq1x3MVGlCxGSRI HuC4bbnz96RFGyiwnD7uCTR5H9nwZ+zVPYaZn3YYWZLg22FjBfzUXNh4ORzD IanceR5zdZ; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Vishwas Manral , ospf@ietf.org, Ronald Bonica , "Romascanu, Dan \(Dan\)" , "MIB Doctors \(E-mail\)" , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org The two (V2 and V3) are incompatible. -DWard On Mar 7, 2008, at 11:37 AM, Joan Cucchiara wrote: > > Hello, > > I do also have one other question. There seems to be > quite a bit of overlap between RFC4750 (OSPFv2 MIB) > and this draft. While I understand that there are obvious > differences between IPv4 and IPv6 addresses, and also > some differences in OSPFv2 vs. OSPFv3, I still see many > of the same MIB objects in the 2 MIB Modules, did the > authors consider using OSPFv2 MIB and doing AUGMENTS > for OSPFv3? > > Please give me some background/history on why a completely > separate MIB Module was done for OSPFv3. > > Thank you, > Joan > > > ----- Original Message ----- From: "Joan Cucchiara" > > To: "Romascanu, Dan (Dan)" ; "Acee Lindem" > ; ; "MIB Doctors (E-mail)" doctors@ietf.org> > Cc: "Ronald Bonica" ; "Abhay Roy" > ; "Ross Callon" ; "Vishwas > Manral" ; "Dan Joyal" ; > "Bert Wijnen" ; "David Ward" > Sent: Friday, March 07, 2008 2:37 AM > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > >> >> Hi Folks, >> >> First is the output from the MIB tools. >> Followed by some General Comments, and then followed by >> fairly specific comments/questions on the MIB. >> >> Thanks, >> Joan >> >> >> SMICNG results: >> ---------------- >> >> E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" >> in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax >> specified >> >> E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" >> must be defined with syntax that includes a range >> >> >> smilint >> ------------ >> severity level requested 6 >> >> line severity problem >> -------------------------- >> >> 2844 5 warning: `InetAddress' object should have an >> accompanied preceding `InetAdressType' object >> (Please see comments below wrt Notifications) >> >> >> >> ID NITS (== 1 warning) >> -------- >> >> == The copyright year in the IETF Trust Copyright Line does not >> match the >> current year >> >> >> >> >> General Comments >> ----------------- >> >> 1) Need to have a read-only conformance. >> >> 2) I would like to understand the use of the single >> DiscontinuityTime object for all the counters in the >> MIB. My thoughts are that having a few more discontinuity >> objects (specifically in tables) would be more beneficial, >> so please give me some feedback on this, so I can understand >> why only one Discontinuity object is used. >> >> 3) Throttling of notifications and Polling Event Counters. >> I think more details of this need to be in the MIB itself. >> Please expand some of these DESCRIPTIONS. >> >> 4) Please note that many of my comments apply to the entire MIB, >> although >> I only commented on the first few objects. Please be sure to >> check the >> entire MIB for an issue. For example, please rename any RowStatus >> object >> with xxxRowStatus, please spell out Interval, etc. >> >> 5) The MIB did not extract using mstrip (MIB tool). >> If possible, could this be fixed? >> >> >> Comments in Order of the document >> ---------------------------------- >> >> 1) (NIT) Header should say: >> Proposed Status: Standards Track >> >> >> 2) (NIT) Expiration date has incorrect year. >> >> >> *) (NIT) please be consistent with using >> RFCXXX vs. MIB tree assignment, so for example >> >> DESCRIPTION >> "The MIB module for OSPF version 3. >> >> Copyright (C) The IETF Trust (2007). >> This version of this MIB module is part of >> RFC XXXX; see the RFC itself for full legal >> notices." >> >> REVISION "200709171200Z" >> DESCRIPTION -- RFC Editor assigns RFC XXXX >> "Initial version, published as RFC XXXX" >> >> ::= { mib-2 YYY } -- to be assigned by IANA >> >> >> >> >> *)Ospfv3UpToRefreshIntervalTc >> >> *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3DeadIntRangeTc >> *) Please spell out Interval and change Tc to TC, >> i.e. Ospfv3DeadIntervalRangeTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3RouterIdTC >> >> *) Please use TC, Ospfv3RouterIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Please add a reference >> >> *) Ospfv3AreaIdTc >> >> *) Please use TC, Ospfv3AreaIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> >> *) Please add a reference >> >> >> *) Ospfv3IfInstIdTc >> >> *) Please Tc to TC, i.e. Ospfv3IfInstIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> >> *) ospfv3RouterId >> >> Isn't this a 32-bit unsigned integer? >> Please add REFERENCE clause. >> >> >> *) ospfv3AreaBdrRtrStatus >> >> Please indicate the value of the flag >> when the router is an area border router. >> (i.e. when the value of this object is true(1)...) >> >> *) ospfv3AsScopeLsaCksumSum >> >> *) should be Unsigned32 >> >> >> *) ospfv3DemandExtensions >> >> Same comment as with the previous object that has SYNTAX of >> TruthValue, >> please specify, when this object has the value of true(1), then >> the router supports demand circuits... >> >> *) ospfv3ReferenceBandwidth >> >> -Please add UNITS >> -Please add DEFVAL >> - Please add REFERENCE >> >> >> *) ospfv3RestartSupport >> >> -Is there a value which could be considered a DEFVAL for >> this object? >> (In general, please review all the read-write objects >> and add DEFVALs if appropriate). >> >> *) ospfv3RestartInterval >> -Is there a value which could be considered a DEFVAL for >> this object? >> >> >> *) ospfv3RestartStrictLsaChecking >> >> Please indicate what true(1) means in the DESCRIPTION >> (Please do this for all objects which contain a >> TruthValue) >> >> *) ospfv3RestartExitRc >> >> What does the Rc stand for, could this be spelled out? >> >> Are any additional objects needed to tell when the >> value of this object changed? >> >> *) ospfv3NotificationEnable >> >> Why is this object needed? Or,in other words, why >> can't RFC3413 be used. >> >> *) ospfv3StubRouterAdvertisement >> >> Need to add DEFVAL >> Please add a REFERENCE >> >> *) ospfv3AreaTable >> >> - This table has a combination of both objects to configure >> areas and statistics for areas. Could this be devided into >> 2 tables one for configuring and one for status/statics? >> >> Additionally, if is not clear to me what happens when an attached >> area is established and then the configuration changes? Can >> the configurable objects be changed? >> >> Also, the counters in this table refer to ospfv3DiscontinuityTime >> but if the OSPFv3 routing process starts-up, then my understanding >> is that these counters might be affected (specifically, >> ospfv3AreaNssTranslatorEvents), >> so I think another discontinuityTime object is needed...please >> comment. >> >> >> *) ospfv3AreaId >> >> Isn't this unsigned? >> >> >> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >> table may have a DEFVAL clause of zero (this is mentioned in >> the DESCRIPTION clauses). >> >> *) ospfv3AreaScopeLsaCksumSum >> >> Should this be Unsigned32? >> >> >> *) ospfv3AreaStatus >> >> Please rename to ospfv3AreaRowStatus >> >> *) ospfv3AreaStubMetric >> >> Is there a DEFVAL for this object? >> >> >> *) ospfv3AreaNssaTranslatorStabInt >> >> Please use entire word Interval >> >> >> >> *) ospfv3AsLsdbSequence >> >> Should this have a range? >> >> *) ospfv3AreaLsdbSequence >> >> (same question, is there a range for this?) >> >> *) ospfv3AreaLsdbAge >> >> Unsigned32 and a range? >> >> What is the value if the DoNotAge Bit is set? >> >> *) ospfv3AreaLsdbChecksum >> >> Should this be unsigned32? >> >> >> *) ospfv3AreaLsdbTypeKnown >> >> Please indicate what true(1) means in the >> DESCRIPTION >> >> *) ospfv3LinkLsdbSequence >> >> Same comment as with the other Sequence numbers, >> should this have a range? Additionally, should these >> sequence numbers have a common TC? >> >> *)ospfv3LinkLsdbAge >> >> same comments and questions >> as with the "Age" object in the prior table? >> >> *) ospfv3LinkLsdbChecksum >> >> Unsigned32? >> >> >> *) ospfv3HostTable >> >> Need to have a storageType object added to this table. >> >> >> >> >> >> *) ospfv3HostStatus >> >> Please rename to ospfv3HostRowStatus >> Usually, this is the last in the list of objects. >> >> *)ospfv3IfTable >> >> Don't understand the REFERENCE here, please explain. >> >> >> Same comment as with the other table, there is mix of >> configuration and status/statistics in this one table. >> Could this be made into 2 tables? >> >> Also, the Counters in this table >> likely need their own discontinuityTime object.... >> >> Can configurable objects change once the interface >> is established (for example, if the interface is pointToPoint?) >> >> >> >> >> *) ospfv3IfTransitDelay >> >> Don't understand the DESCRIPTION here. Could you >> please expand. >> >> Is there a REFERENCE that could be added? >> >> *) ospfv3IfStatus >> >> Please rename to ospfv3IfRowStatus >> >> *) ospfv3IfAdminStat >> >> Would an OperStatus object be beneficial in this >> table? >> >> *) ospfv3IfDemandNbrProbeRetxLimit >> >> Retx is used for Retransmission, elsewhere Retrans >> was used. Please be consistant. >> >> *) ospfv3VirtIfTable >> >> Don't understand the reference here. If this is >> an IPv6/V3 specific table then why are you >> Refering to OSPFv2? Is this correct? Additionally, >> could a OSPFv3 REFERENCE be added also? >> >> Same comments as with the other tables that have >> a mix of config and status/statistics objects. >> >> Please change RowStatus objects to have RowStatus >> at the end of their name. >> >> *) ospfv3NbrTable >> >> Same question as to how the Counters in this table >> can successfully use ospfv3DiscontinuityTime. In other >> words, if this table is specific to neighbors, then >> the counters are also, so there might be (at least it >> seems to me) a case where an entry in this table is >> affected and neighbor counters suffer a discontinuity >> but the ospfv3DiscontinuityTime may not. Please comment. >> >> >> *) ospfv3NbrTable and ospfv3CfgNbrTable >> >> What is the relationship between these 2 tables? >> The indexing is different between the 2 tables and so >> I'm wondering what the relationship is between them. >> >> >> >> *) ospfv3AreaAggregateRouteTag >> >> Is this Unsigned32? >> >> >> Notifications >> ------------ >> >> In general the accessible-for-notify objects should probably be >> changed into read-only objects. Additionally, a timestamp should >> be associated with some of these. There is an assumption made that >> it is better to send out notifications rather than poll, but I'd >> rather give the operator the choice on that. >> >> >> >> >> >> >> >> Compliance Statements >> ------------------------- >> >> * Need a Read-only compliance statement. >> It is missing. >> >> --- >> >> >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 7 09:49:45 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 98F0528C590; Fri, 7 Mar 2008 09:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.018 X-Spam-Level: X-Spam-Status: No, score=-100.018 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 QIqD0CLKSvsc; Fri, 7 Mar 2008 09:49:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3028C73D; Fri, 7 Mar 2008 09:49:43 -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 206413A6913; Fri, 7 Mar 2008 09:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 TYI6T+dWvb+9; Fri, 7 Mar 2008 09:49:40 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 46BF83A6C71; Fri, 7 Mar 2008 09:49:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BD79EADFE53; Fri, 7 Mar 2008 09:48:49 -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 21985-07; Fri, 7 Mar 2008 09:48:49 -0800 (PST) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 996B2ADFE51; Fri, 7 Mar 2008 09:48:47 -0800 (PST) In-Reply-To: <039601c88079$dd9d97b0$6601a8c0@JoanPC> References: <039601c88079$dd9d97b0$6601a8c0@JoanPC> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Acee Lindem Date: Fri, 7 Mar 2008 12:48:46 -0500 To: "Joan Cucchiara" X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: Vishwas Manral , ospf@ietf.org, Ronald Bonica , "Romascanu, Dan \(Dan\)" , "MIB Doctors \(E-mail\)" , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Joan, Thanks much for the thorough and prompt review. There are some basic semantic differences between OSPFv2 and OSPFv3. Hence, I'm not sure if it is feasible to combine the MIBs. Also, over the long term our intent is to incorporate new function into OSPFv3 that will not be contained in OSPFv2. Finally, we've been working on this MIB for so long that I don't think it is in the best interest of the OSPF WG to even attempt consolidation. Thanks, Acee On Mar 7, 2008, at 12:37 PM, Joan Cucchiara wrote: > > Hello, > > I do also have one other question. There seems to be > quite a bit of overlap between RFC4750 (OSPFv2 MIB) > and this draft. While I understand that there are obvious > differences between IPv4 and IPv6 addresses, and also > some differences in OSPFv2 vs. OSPFv3, I still see many > of the same MIB objects in the 2 MIB Modules, did the > authors consider using OSPFv2 MIB and doing AUGMENTS > for OSPFv3? > > Please give me some background/history on why a completely > separate MIB Module was done for OSPFv3. > > Thank you, > Joan > > > ----- Original Message ----- From: "Joan Cucchiara" > > To: "Romascanu, Dan (Dan)" ; "Acee Lindem" > ; ; "MIB Doctors (E-mail)" doctors@ietf.org> > Cc: "Ronald Bonica" ; "Abhay Roy" > ; "Ross Callon" ; "Vishwas > Manral" ; "Dan Joyal" ; > "Bert Wijnen" ; "David Ward" > Sent: Friday, March 07, 2008 2:37 AM > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > >> >> Hi Folks, >> >> First is the output from the MIB tools. >> Followed by some General Comments, and then followed by >> fairly specific comments/questions on the MIB. >> >> Thanks, >> Joan >> >> >> SMICNG results: >> ---------------- >> >> E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" >> in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax >> specified >> >> E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" >> must be defined with syntax that includes a range >> >> >> smilint >> ------------ >> severity level requested 6 >> >> line severity problem >> -------------------------- >> >> 2844 5 warning: `InetAddress' object should have an >> accompanied preceding `InetAdressType' object >> (Please see comments below wrt Notifications) >> >> >> >> ID NITS (== 1 warning) >> -------- >> >> == The copyright year in the IETF Trust Copyright Line does not >> match the >> current year >> >> >> >> >> General Comments >> ----------------- >> >> 1) Need to have a read-only conformance. >> >> 2) I would like to understand the use of the single >> DiscontinuityTime object for all the counters in the >> MIB. My thoughts are that having a few more discontinuity >> objects (specifically in tables) would be more beneficial, >> so please give me some feedback on this, so I can understand >> why only one Discontinuity object is used. >> >> 3) Throttling of notifications and Polling Event Counters. >> I think more details of this need to be in the MIB itself. >> Please expand some of these DESCRIPTIONS. >> >> 4) Please note that many of my comments apply to the entire MIB, >> although >> I only commented on the first few objects. Please be sure to >> check the >> entire MIB for an issue. For example, please rename any RowStatus >> object >> with xxxRowStatus, please spell out Interval, etc. >> >> 5) The MIB did not extract using mstrip (MIB tool). >> If possible, could this be fixed? >> >> >> Comments in Order of the document >> ---------------------------------- >> >> 1) (NIT) Header should say: >> Proposed Status: Standards Track >> >> >> 2) (NIT) Expiration date has incorrect year. >> >> >> *) (NIT) please be consistent with using >> RFCXXX vs. MIB tree assignment, so for example >> >> DESCRIPTION >> "The MIB module for OSPF version 3. >> >> Copyright (C) The IETF Trust (2007). >> This version of this MIB module is part of >> RFC XXXX; see the RFC itself for full legal >> notices." >> >> REVISION "200709171200Z" >> DESCRIPTION -- RFC Editor assigns RFC XXXX >> "Initial version, published as RFC XXXX" >> >> ::= { mib-2 YYY } -- to be assigned by IANA >> >> >> >> >> *)Ospfv3UpToRefreshIntervalTc >> >> *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3DeadIntRangeTc >> *) Please spell out Interval and change Tc to TC, >> i.e. Ospfv3DeadIntervalRangeTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3RouterIdTC >> >> *) Please use TC, Ospfv3RouterIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Please add a reference >> >> *) Ospfv3AreaIdTc >> >> *) Please use TC, Ospfv3AreaIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> >> *) Please add a reference >> >> >> *) Ospfv3IfInstIdTc >> >> *) Please Tc to TC, i.e. Ospfv3IfInstIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> >> *) ospfv3RouterId >> >> Isn't this a 32-bit unsigned integer? >> Please add REFERENCE clause. >> >> >> *) ospfv3AreaBdrRtrStatus >> >> Please indicate the value of the flag >> when the router is an area border router. >> (i.e. when the value of this object is true(1)...) >> >> *) ospfv3AsScopeLsaCksumSum >> >> *) should be Unsigned32 >> >> >> *) ospfv3DemandExtensions >> >> Same comment as with the previous object that has SYNTAX of >> TruthValue, >> please specify, when this object has the value of true(1), then >> the router supports demand circuits... >> >> *) ospfv3ReferenceBandwidth >> >> -Please add UNITS >> -Please add DEFVAL >> - Please add REFERENCE >> >> >> *) ospfv3RestartSupport >> >> -Is there a value which could be considered a DEFVAL for >> this object? >> (In general, please review all the read-write objects >> and add DEFVALs if appropriate). >> >> *) ospfv3RestartInterval >> -Is there a value which could be considered a DEFVAL for >> this object? >> >> >> *) ospfv3RestartStrictLsaChecking >> >> Please indicate what true(1) means in the DESCRIPTION >> (Please do this for all objects which contain a >> TruthValue) >> >> *) ospfv3RestartExitRc >> >> What does the Rc stand for, could this be spelled out? >> >> Are any additional objects needed to tell when the >> value of this object changed? >> >> *) ospfv3NotificationEnable >> >> Why is this object needed? Or,in other words, why >> can't RFC3413 be used. >> >> *) ospfv3StubRouterAdvertisement >> >> Need to add DEFVAL >> Please add a REFERENCE >> >> *) ospfv3AreaTable >> >> - This table has a combination of both objects to configure >> areas and statistics for areas. Could this be devided into >> 2 tables one for configuring and one for status/statics? >> >> Additionally, if is not clear to me what happens when an attached >> area is established and then the configuration changes? Can >> the configurable objects be changed? >> >> Also, the counters in this table refer to ospfv3DiscontinuityTime >> but if the OSPFv3 routing process starts-up, then my understanding >> is that these counters might be affected (specifically, >> ospfv3AreaNssTranslatorEvents), >> so I think another discontinuityTime object is needed...please >> comment. >> >> >> *) ospfv3AreaId >> >> Isn't this unsigned? >> >> >> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >> table may have a DEFVAL clause of zero (this is mentioned in >> the DESCRIPTION clauses). >> >> *) ospfv3AreaScopeLsaCksumSum >> >> Should this be Unsigned32? >> >> >> *) ospfv3AreaStatus >> >> Please rename to ospfv3AreaRowStatus >> >> *) ospfv3AreaStubMetric >> >> Is there a DEFVAL for this object? >> >> >> *) ospfv3AreaNssaTranslatorStabInt >> >> Please use entire word Interval >> >> >> >> *) ospfv3AsLsdbSequence >> >> Should this have a range? >> >> *) ospfv3AreaLsdbSequence >> >> (same question, is there a range for this?) >> >> *) ospfv3AreaLsdbAge >> >> Unsigned32 and a range? >> >> What is the value if the DoNotAge Bit is set? >> >> *) ospfv3AreaLsdbChecksum >> >> Should this be unsigned32? >> >> >> *) ospfv3AreaLsdbTypeKnown >> >> Please indicate what true(1) means in the >> DESCRIPTION >> >> *) ospfv3LinkLsdbSequence >> >> Same comment as with the other Sequence numbers, >> should this have a range? Additionally, should these >> sequence numbers have a common TC? >> >> *)ospfv3LinkLsdbAge >> >> same comments and questions >> as with the "Age" object in the prior table? >> >> *) ospfv3LinkLsdbChecksum >> >> Unsigned32? >> >> >> *) ospfv3HostTable >> >> Need to have a storageType object added to this table. >> >> >> >> >> >> *) ospfv3HostStatus >> >> Please rename to ospfv3HostRowStatus >> Usually, this is the last in the list of objects. >> >> *)ospfv3IfTable >> >> Don't understand the REFERENCE here, please explain. >> >> >> Same comment as with the other table, there is mix of >> configuration and status/statistics in this one table. >> Could this be made into 2 tables? >> >> Also, the Counters in this table >> likely need their own discontinuityTime object.... >> >> Can configurable objects change once the interface >> is established (for example, if the interface is pointToPoint?) >> >> >> >> >> *) ospfv3IfTransitDelay >> >> Don't understand the DESCRIPTION here. Could you >> please expand. >> >> Is there a REFERENCE that could be added? >> >> *) ospfv3IfStatus >> >> Please rename to ospfv3IfRowStatus >> >> *) ospfv3IfAdminStat >> >> Would an OperStatus object be beneficial in this >> table? >> >> *) ospfv3IfDemandNbrProbeRetxLimit >> >> Retx is used for Retransmission, elsewhere Retrans >> was used. Please be consistant. >> >> *) ospfv3VirtIfTable >> >> Don't understand the reference here. If this is >> an IPv6/V3 specific table then why are you >> Refering to OSPFv2? Is this correct? Additionally, >> could a OSPFv3 REFERENCE be added also? >> >> Same comments as with the other tables that have >> a mix of config and status/statistics objects. >> >> Please change RowStatus objects to have RowStatus >> at the end of their name. >> >> *) ospfv3NbrTable >> >> Same question as to how the Counters in this table >> can successfully use ospfv3DiscontinuityTime. In other >> words, if this table is specific to neighbors, then >> the counters are also, so there might be (at least it >> seems to me) a case where an entry in this table is >> affected and neighbor counters suffer a discontinuity >> but the ospfv3DiscontinuityTime may not. Please comment. >> >> >> *) ospfv3NbrTable and ospfv3CfgNbrTable >> >> What is the relationship between these 2 tables? >> The indexing is different between the 2 tables and so >> I'm wondering what the relationship is between them. >> >> >> >> *) ospfv3AreaAggregateRouteTag >> >> Is this Unsigned32? >> >> >> Notifications >> ------------ >> >> In general the accessible-for-notify objects should probably be >> changed into read-only objects. Additionally, a timestamp should >> be associated with some of these. There is an assumption made that >> it is better to send out notifications rather than poll, but I'd >> rather give the operator the choice on that. >> >> >> >> >> >> >> >> Compliance Statements >> ------------------------- >> >> * Need a Read-only compliance statement. >> It is missing. >> >> --- >> >> >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 7 11:23:55 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 42B6E28C441; Fri, 7 Mar 2008 11:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.653 X-Spam-Level: X-Spam-Status: No, score=-99.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, 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 PK+s+q7Ovzpq; Fri, 7 Mar 2008 11:23:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BFC3A6BF7; Fri, 7 Mar 2008 11:23:36 -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 B5B1528C0FD for ; Fri, 7 Mar 2008 11:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 XhfvoUgJtAr6 for ; Fri, 7 Mar 2008 11:23:33 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id D0F6B3A6BF7 for ; Fri, 7 Mar 2008 11:23:32 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so549088fgg.41 for ; Fri, 07 Mar 2008 11:23:21 -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:references; bh=yZYoZgZ7HD+DLbQG+U6RKyQS6ozFFCwZ+ZAitlFzsf4=; b=jLbSVYpqJVRdSoXectl6eYUJcBtwVMUDw/dTDPRvvudTGwDIjpz+PFuSlB4JtIk7aecHD38GB4LCh0JyildZR+zShvdc4bIoG8b71aE4F401reKiTm1RhfWact8gkEzLJw+W487TIAiImM5d+6nql3H9HcfclD9WjBCpX/4ssI0= 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:references; b=QRGGKxBCRWg57KYWB6zSlfEkerWDzgBmCyuq9mQUTaA1qt7lNt71IK5HD8VoWYz3dWuW92bJ1nbJUgIhYEIGiLBUqegHUx4vC5cfvz3qVzBMy+jyJwJKN71AKZXQwqoN9TYN7Z0nRKh06uQfFWh1pTJsxYtVY9rooR7OF0TH0yg= Received: by 10.86.78.4 with SMTP id a4mr1927261fgb.3.1204917801173; Fri, 07 Mar 2008 11:23:21 -0800 (PST) Received: by 10.86.29.1 with HTTP; Fri, 7 Mar 2008 11:23:21 -0800 (PST) Message-ID: <6b63093f0803071123s3b830cdcte8b24c8d27a1f325@mail.gmail.com> Date: Sat, 8 Mar 2008 00:53:21 +0530 From: "Lokesh Jain" To: "Acee Lindem" In-Reply-To: <24EF29F9-5B7B-41A7-B5C1-5215750DF01B@redback.com> MIME-Version: 1.0 References: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com> <24EF29F9-5B7B-41A7-B5C1-5215750DF01B@redback.com> Cc: ospf@ietf.org Subject: Re: [OSPF] RFC 4577 Query 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="===============1984678753==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1984678753== Content-Type: multipart/alternative; boundary="----=_Part_3668_5974318.1204917801175" ------=_Part_3668_5974318.1204917801175 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Acee, Thanks for the reply. I got your point. But my doubt still remains. Are we directly migrating from legacy OSPF backbones to BGP/MPLS VPN Backbone with OSPF on PE/CE links or earlier BGP was used on PE/CE links? If BGP was used, then the complexity/procedures of BGP/IGP interaction (special in this case since we want to redistribute AS-External routes as Inter-area routes) defined by RFC 4577 would already be in existence. We are just moving this interaction from CE to PE to save CE from the extra effort and provide transparency. Am I correct ? On Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem wrote: > Hi Lokesh, > > On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote: > > > Hi All, > > > > In RFC 4577 it states that earlier PE-CE link used BGP but to > > provide certain advantages to customer, OSPF would be a better > > choice between PE-CE link. > > But to do that we have to modify BGP /OSPF interaction so that > > routes are distributed as inter-area routes and not as AS-External > > routes. > > > > My doubt is: > > > > In earlier scenario, CE would be running an instance of BGP and > > some other IGP, say OSPF. In that case also the routes distributed > > in a customer VPN site would be AS-External routes and not inter- > > area routes. How was that handled in previous case? Or is it the > > just the case of moving BGP/OSPF interaction from CE to PE? > > > > Please guide me regarding this. I must be missing on some point here. > > > The point is for an ISP to provide a transparent Layer 3 VPN service. > If the CE is forced to handle all the complexity of the BGP/IGP > interaction, this is hardly transparent. RFC 4577 mostly succeeds in > this goal and is widely deployed. > > Hope this Helps, > Acee > > > > > > > -- > > ~~~~~~~~~~~~~ > > Thanks & Regards, > > ~~~~~~~~~~~~~ > > Lokesh Jain > > Senior Software Engineer, > > Samsung India Software Operations Pvt. Ltd., > > Bagmane Tech Park, C V Raman Nagar, > > Bangalore. > > Mob: 9880611348 > > ----------------------------------------------------- > > You always miss 100% of the chances u don't take > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > -- ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take ------=_Part_3668_5974318.1204917801175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Acee,

Thanks for the reply. I got your point.

But my doubt still remains.

Are we directly migrating from legacy OSPF backbones to BGP/MPLS VPN Backbone with OSPF on PE/CE links or earlier BGP was used on PE/CE links?
If BGP was used, then the complexity/procedures of BGP/IGP interaction (special in this case since we want to redistribute AS-External routes as Inter-area routes) defined by RFC 4577 would already be in existence. We are just moving this interaction from CE to PE to save CE from the extra effort and provide transparency.

Am I correct ?

On Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem <acee@redback.com> wrote:
Hi Lokesh,

On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote:

> Hi All,
>
> In RFC 4577 it states that earlier PE-CE link used BGP but to
> provide certain advantages to customer, OSPF would be a better
> choice between PE-CE link.
> But to do that we have to modify BGP /OSPF interaction so that
> routes are distributed as inter-area routes and not as AS-External
> routes.
>
> My doubt is:
>
> In earlier scenario, CE would be running an instance of BGP and
> some other IGP, say OSPF. In that case also the routes distributed
> in a customer VPN site would be AS-External routes and not inter-
> area routes. How was that handled in previous case? Or is it the
> just the case of moving BGP/OSPF interaction from CE to PE?
>
> Please guide me regarding this. I must be missing on some point here.


The point is for an ISP to provide a transparent Layer 3 VPN service.
If the CE is forced to handle all the complexity of the BGP/IGP
interaction, this is hardly transparent. RFC 4577 mostly succeeds in
this goal and is widely deployed.

Hope this Helps,
Acee

>
>
> --
> ~~~~~~~~~~~~~
> Thanks & Regards,
> ~~~~~~~~~~~~~
> Lokesh Jain
> Senior Software Engineer,
> Samsung India Software Operations Pvt. Ltd.,
> Bagmane Tech Park, C V Raman Nagar,
> Bangalore.
> Mob: 9880611348
> -----------------------------------------------------
> You always miss 100% of the chances u don't take
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf




--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take ------=_Part_3668_5974318.1204917801175-- --===============1984678753== 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 --===============1984678753==-- From ospf-bounces@ietf.org Sat Mar 8 06:21:19 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 9C29228CF0D; Sat, 8 Mar 2008 06:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.239 X-Spam-Level: X-Spam-Status: No, score=-99.239 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, 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 1NprkWI3zPCj; Sat, 8 Mar 2008 06:21:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F462933EE; Sat, 8 Mar 2008 05:55:50 -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 04C0528E854 for ; Sat, 8 Mar 2008 05:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 f2XgdoLMrhRa for ; Sat, 8 Mar 2008 05:55:32 -0800 (PST) Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by core3.amsl.com (Postfix) with ESMTP id DA2EA28DEE5 for ; Fri, 7 Mar 2008 13:58:13 -0800 (PST) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 13:57:59 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2037930BD@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <6b63093f0803071123s3b830cdcte8b24c8d27a1f325@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] RFC 4577 Query Thread-Index: AciAiOhzRbXbRiu6TNayYIpVLVwmVgAEIKWw References: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com><24EF29F9-5B7B-41A7-B5C1-5215750DF01B@redback.com> <6b63093f0803071123s3b830cdcte8b24c8d27a1f325@mail.gmail.com> From: "Sina Mirtorabi" To: "Lokesh Jain" , "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] RFC 4577 Query 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="===============2020501659==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============2020501659== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8809E.4F868383" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8809E.4F868383 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lokesh, =20 When you are running OSPF and migrating to a MPLS services, there are different options for PE-CE routing protocol. If you want to keep your OSPF transparency, then one has to run OSPF on PE-CE links. If you are running BGP then you would be exposed to dealing with external / internal route preference if there is any backdoor connectivity between the sites. =20 In the latter case in order to avoid the backdoor link between two sites to be preferred, either you have to remove the backdoor or run BGP (or any other instance) so that OSPF route over the backdoor link becomes also external and could be compared to CE advertised external route learned over MPLS cloud. =20 One can conceive that the intelligence for BGP-OSPF interaction could be put on CE and now CE could run BGP with PE without impacting OSPF transparency. There are pros and cons to this which I don't want to debate here. We published a proposal some time back (although it was never presented / announced). You can find a link to it at =20 http://internet-drafts.osmirror.nl/draft-mirtorabi-l3vpn-igp-transparenc y-00.txt =20 thanks Sina =20 =20 ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Lokesh Jain Sent: Friday, March 07, 2008 11:23 AM To: Acee Lindem Cc: ospf@ietf.org Subject: Re: [OSPF] RFC 4577 Query =20 Hi Acee,=20 Thanks for the reply. I got your point. But my doubt still remains.=20 Are we directly migrating from legacy OSPF backbones to BGP/MPLS VPN Backbone with OSPF on PE/CE links or earlier BGP was used on PE/CE links? If BGP was used, then the complexity/procedures of BGP/IGP interaction (special in this case since we want to redistribute AS-External routes as Inter-area routes) defined by RFC 4577 would already be in existence. We are just moving this interaction from CE to PE to save CE from the extra effort and provide transparency.=20 Am I correct ? On Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem wrote: Hi Lokesh, On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote: > Hi All, > > In RFC 4577 it states that earlier PE-CE link used BGP but to > provide certain advantages to customer, OSPF would be a better > choice between PE-CE link. > But to do that we have to modify BGP /OSPF interaction so that > routes are distributed as inter-area routes and not as AS-External > routes. > > My doubt is: > > In earlier scenario, CE would be running an instance of BGP and > some other IGP, say OSPF. In that case also the routes distributed > in a customer VPN site would be AS-External routes and not inter- > area routes. How was that handled in previous case? Or is it the > just the case of moving BGP/OSPF interaction from CE to PE? > > Please guide me regarding this. I must be missing on some point here. The point is for an ISP to provide a transparent Layer 3 VPN service. If the CE is forced to handle all the complexity of the BGP/IGP interaction, this is hardly transparent. RFC 4577 mostly succeeds in this goal and is widely deployed. Hope this Helps, Acee > > > -- > ~~~~~~~~~~~~~ > Thanks & Regards, > ~~~~~~~~~~~~~ > Lokesh Jain > Senior Software Engineer, > Samsung India Software Operations Pvt. Ltd., > Bagmane Tech Park, C V Raman Nagar, > Bangalore. > Mob: 9880611348 > ----------------------------------------------------- > You always miss 100% of the chances u don't take > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --=20 ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take=20 ------_=_NextPart_001_01C8809E.4F868383 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lokesh,

=

 

When you are running OSPF and = migrating to a MPLS services, there are different options for PE-CE routing protocol. = If you want to keep your OSPF transparency, then one has to run OSPF on PE-CE = links. If you are running BGP then you would be exposed to dealing with external / internal route preference if there is any backdoor connectivity between = the sites.

 

In the latter case in order to = avoid the backdoor link between two sites to be preferred, either you have to = remove the backdoor or run BGP (or any other instance) so that OSPF route over the backdoor link becomes also external and could be compared to CE = advertised external route learned over MPLS cloud.

 

One can conceive that the = intelligence for BGP-OSPF interaction could be put on CE and now CE could run BGP with PE without impacting OSPF transparency. There are pros and cons to this = which I don’t want to debate here. We published a proposal some time back = (although it was never presented / announced). You can find a link to it = at

 

http://internet-drafts.osmirror.nl/draft-mirtorabi-l3vpn= -igp-transparency-00.txt

 

thanks

Sina

 

 

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Lokesh Jain
Sent: Friday, March 07, = 2008 11:23 AM
To: Acee Lindem
Cc: ospf@ietf.org
Subject: Re: [OSPF] RFC = 4577 Query

 

Hi Acee,

Thanks for the reply. I got your point.

But my doubt still remains.

Are we directly migrating from legacy OSPF backbones to BGP/MPLS VPN = Backbone with OSPF on PE/CE links or earlier BGP was used on PE/CE links?
If BGP was used, then the complexity/procedures of BGP/IGP interaction = (special in this case since we want to redistribute AS-External routes as = Inter-area routes) defined by RFC 4577 would already be in existence. We are just = moving this interaction from CE to PE to save CE from the extra effort and = provide transparency.

Am I correct ?

On Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem <acee@redback.com> = wrote:

Hi Lokesh,


On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote:

> Hi All,
>
> In RFC 4577 it states that earlier PE-CE link used BGP but to
> provide certain advantages to customer, OSPF would be a better
> choice between PE-CE link.
> But to do that we have to modify BGP /OSPF interaction so that
> routes are distributed as inter-area routes and not as = AS-External
> routes.
>
> My doubt is:
>
> In earlier scenario, CE would be running an instance of BGP and
> some other IGP, say OSPF. In that case also the routes = distributed
> in a customer VPN site would be AS-External routes and not = inter-
> area routes. How was that handled in previous case? Or is it = the
> just the case of moving BGP/OSPF interaction from CE to PE?
>
> Please guide me regarding this. I must be missing on some point = here.

The point is for an ISP to provide a transparent Layer 3 VPN = service.
If the CE is forced to handle all the complexity of the BGP/IGP
interaction, this is hardly transparent. RFC 4577 mostly succeeds in
this goal and is widely deployed.

Hope this Helps,
Acee


>
>
> --
> ~~~~~~~~~~~~~
> Thanks & Regards,
> ~~~~~~~~~~~~~
> Lokesh Jain
> Senior Software Engineer,
> Samsung India Software Operations Pvt. Ltd.,
> Bagmane Tech Park, C V Raman Nagar,
> Bangalore.
> Mob: 9880611348
> -----------------------------------------------------
> You always miss 100% of the chances u don't = take

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




--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take =

------_=_NextPart_001_01C8809E.4F868383-- --===============2020501659== 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 --===============2020501659==-- From ospf-bounces@ietf.org Sat Mar 8 06:24:23 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 4F51E3A766B; Sat, 8 Mar 2008 06:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.772 X-Spam-Level: X-Spam-Status: No, score=-99.772 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, 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 GjfGdTa8h+iy; Sat, 8 Mar 2008 06:24:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DF228CAE7; Sat, 8 Mar 2008 06:10:22 -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 3806E28CEAD for ; Sat, 8 Mar 2008 06:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 HEFdZpbpzGbz for ; Sat, 8 Mar 2008 06:10:18 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 101AD28DB63 for ; Fri, 7 Mar 2008 13:27:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 748439D2AB2; Fri, 7 Mar 2008 13:26:58 -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 28447-07; Fri, 7 Mar 2008 13:26:58 -0800 (PST) Received: from [ZK?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E904E9D2AB0; Fri, 7 Mar 2008 13:26:57 -0800 (PST) In-Reply-To: <6b63093f0803071123s3b830cdcte8b24c8d27a1f325@mail.gmail.com> References: <6b63093f0803070216h5a2524cdtdb8269195e72c3e@mail.gmail.com> <24EF29F9-5B7B-41A7-B5C1-5215750DF01B@redback.com> <6b63093f0803071123s3b830cdcte8b24c8d27a1f325@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Fri, 7 Mar 2008 16:26:56 -0500 To: Lokesh Jain X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] RFC 4577 Query 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="===============0898751314==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0898751314== Content-Type: multipart/alternative; boundary=Apple-Mail-81--1015250125 --Apple-Mail-81--1015250125 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Lokesh, This is probably a question for the L3VPN WG :^) However, my understanding is that this is targeted at migration from an OSPF network using dedicated links (not over a VPN). The brief discussion of BGP/OSPF in the CE is in comparison to RFC 4577. Thanks, Acee On Mar 7, 2008, at 2:23 PM, Lokesh Jain wrote: > Hi Acee, > > Thanks for the reply. I got your point. > > But my doubt still remains. > > Are we directly migrating from legacy OSPF backbones to BGP/MPLS > VPN Backbone with OSPF on PE/CE links or earlier BGP was used on PE/ > CE links? > If BGP was used, then the complexity/procedures of BGP/IGP > interaction (special in this case since we want to redistribute AS- > External routes as Inter-area routes) defined by RFC 4577 would > already be in existence. We are just moving this interaction from > CE to PE to save CE from the extra effort and provide transparency. > > Am I correct ? > > On Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem wrote: > Hi Lokesh, > > On Mar 7, 2008, at 5:16 AM, Lokesh Jain wrote: > > > Hi All, > > > > In RFC 4577 it states that earlier PE-CE link used BGP but to > > provide certain advantages to customer, OSPF would be a better > > choice between PE-CE link. > > But to do that we have to modify BGP /OSPF interaction so that > > routes are distributed as inter-area routes and not as AS-External > > routes. > > > > My doubt is: > > > > In earlier scenario, CE would be running an instance of BGP and > > some other IGP, say OSPF. In that case also the routes distributed > > in a customer VPN site would be AS-External routes and not inter- > > area routes. How was that handled in previous case? Or is it the > > just the case of moving BGP/OSPF interaction from CE to PE? > > > > Please guide me regarding this. I must be missing on some point > here. > > > The point is for an ISP to provide a transparent Layer 3 VPN service. > If the CE is forced to handle all the complexity of the BGP/IGP > interaction, this is hardly transparent. RFC 4577 mostly succeeds in > this goal and is widely deployed. > > Hope this Helps, > Acee > > > > > > > -- > > ~~~~~~~~~~~~~ > > Thanks & Regards, > > ~~~~~~~~~~~~~ > > Lokesh Jain > > Senior Software Engineer, > > Samsung India Software Operations Pvt. Ltd., > > Bagmane Tech Park, C V Raman Nagar, > > Bangalore. > > Mob: 9880611348 > > ----------------------------------------------------- > > You always miss 100% of the chances u don't take > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > -- > ~~~~~~~~~~~~~ > Thanks & Regards, > ~~~~~~~~~~~~~ > Lokesh Jain > Senior Software Engineer, > Samsung India Software Operations Pvt. Ltd., > Bagmane Tech Park, C V Raman Nagar, > Bangalore. > Mob: 9880611348 > ----------------------------------------------------- > You always miss 100% of the chances u don't take --Apple-Mail-81--1015250125 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Lokesh,=A0
This is probably a question for the L3VPN WG :^) = However, my understanding is that this is targeted at migration from an = OSPF network using dedicated links (not over a VPN). The brief = discussion of BGP/OSPF in the CE is in comparison to RFC = 4577.=A0
Thanks,
Acee
On Mar 7, = 2008, at 2:23 PM, Lokesh Jain wrote:

Hi Acee, =

Thanks for the reply. I got your point.

But my doubt = still remains.

Are we directly migrating from legacy OSPF = backbones to BGP/MPLS VPN Backbone with OSPF on PE/CE links or earlier = BGP was used on PE/CE links?
If BGP was used, then the = complexity/procedures of BGP/IGP interaction (special in this case since = we want to redistribute AS-External routes as Inter-area routes) defined = by RFC 4577 would already be in existence. We are just moving this = interaction from CE to PE to save CE from the extra effort and provide = transparency.

Am I correct ?

On= Fri, Mar 7, 2008 at 8:23 PM, Acee Lindem <acee@redback.com> = wrote:
Hi Lokesh,

On Mar 7, 2008, at 5:16 = AM, Lokesh Jain wrote:

> Hi All,
>
> In RFC = 4577 it states that earlier PE-CE link used BGP but to
> provide = certain advantages to customer, OSPF would be a better
> choice = between PE-CE link.
> But to do that we have to modify BGP /OSPF = interaction so that
> routes are distributed as inter-area routes = and not as AS-External
> routes.
>
> My doubt = is:
>
> In earlier scenario, CE would be running an = instance of BGP and
> some other IGP, say OSPF. In that case also = the routes distributed
> in a customer VPN site would be = AS-External routes and not inter-
> area routes. How was that = handled in previous case? Or is it the
> just the case of moving = BGP/OSPF interaction from CE to PE?
>
> Please guide me = regarding this. I must be missing on some point here.


=
The point is for an ISP to provide a transparent Layer 3 VPN = service.
If the CE is forced to handle all the complexity of the = BGP/IGP
interaction, this is hardly transparent. RFC 4577 mostly = succeeds in
this goal and is widely deployed.

Hope this = Helps,
Acee

>
>
> = --
> ~~~~~~~~~~~~~
> Thanks & Regards,
> = ~~~~~~~~~~~~~
> Lokesh Jain
> Senior Software = Engineer,
> Samsung India Software Operations Pvt. Ltd.,
> = Bagmane Tech Park, C V Raman Nagar,
> Bangalore.
> Mob: = 9880611348
> = -----------------------------------------------------
> You = always miss 100% of the chances u don't take
> = _______________________________________________
> OSPF mailing = list
> OSPF@ietf.org
= > https://www.ietf.org/mailman/listinfo/ospf
=



-- =
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh = Jain
Senior Software Engineer,
Samsung India Software Operations = Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: = 9880611348
-----------------------------------------------------
You= always miss 100% of the chances u don't = take

= --Apple-Mail-81--1015250125-- --===============0898751314== 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 --===============0898751314==-- From ospf-bounces@ietf.org Sun Mar 9 01:02: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 77C1D3A6D36; Sun, 9 Mar 2008 01:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.323 X-Spam-Level: X-Spam-Status: No, score=-99.323 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 rNmcIgZC77-Y; Sun, 9 Mar 2008 01:02:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EDA3A6C09; Sun, 9 Mar 2008 01:02: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 5FE313A6C09 for ; Sun, 9 Mar 2008 01:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 7PJf25Rul5P1 for ; Sun, 9 Mar 2008 01:02:29 -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 766CF3A6C30 for ; Sun, 9 Mar 2008 01:02:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lzP5L0V9ZV/04v9W48++MmKeFcBo51Jr13Fvzlz/058Qvq/dCTeKXOrDCu8poL1J; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.24.205] (helo=earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JYHNx-0006PB-2f; Sun, 09 Mar 2008 05:00:05 -0400 Message-ID: <46B36948.9E7A1BD0@earthlink.net> Date: Fri, 03 Aug 2007 10:43:36 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Acee Lindem References: <66A3A59B-F3DA-437C-9107-67C36A4B93F7@redback.com> <4B7DAC3FEFD35D4A96BDD011699050140A4245F9@zrtphxm1.corp.nortel.com> <93E269EB-87EB-4B6F-B212-B3E15C049B55@redback.com> <46B21BEF.F72A2FB2@earthlink.net> <46B25A86.72B967B9@earthlink.net> X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79eedd900d33144736666e13b607d25796350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.24.205 Cc: OSPF List Subject: Re: [OSPF] Removal of MOSPF from 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 Acee Lindem, What I am sure about MOSPF for OSPFv3. - Ethereal and other networking debuggers with different versions identifyied this bit wrt MOSPF. - Almost all OSPFv3 versions have some type of support to ignore the bit and the LSA type. Some of these routers are from companies that no longer suport the router or no longer exist. - Zebra and other public domain implementations had at least 1 Acee Lindem wrote: > > Mitchell, > > On Aug 2, 2007, at 6:28 PM, Erblichs wrote: > > > Yes Acee, I think we did, > > > > Are you 100% sure that NO-ONE generated a MOSPF > > implimentation OR used it for something ELSE OR > > if this bit is set is going to do WEIRD things. > > If not then WHY NOT be as careful as possible? > > Again, this is MOSPF for OSPFv3. > > > > > I just think that this isn't the ONLY thing in the > > current or future that COULD/SHOULD be DEPRECATED. > > > > We could let a larger audience OUTSIDE of this > > mail alias be AWARE that this/these things are intended > > to be DEPRCATED/REMOVED. > > > > It has been around for years? > > Document it for 6 months, and set a clock, and MAYBE > > have implimentations check whether this bit is set? > > However, this last bit introduces the chicken and > > egg problem, That's why it needs to be a 1-time FYI > > msg if generated. > > > > Then get rid of it... > > We'll re-WG last call the updated OSPFv3 document without the MOSPF > for OSPFv3 extensions. Given that we've discussed this a number of > times, this should be ample time. Here is a link to the initial E- > mail in one such discussion: > > http://www1.ietf.org/mail-archive/web/ospf/current/msg03798.html > > This was more than 18 months ago. You were one of the main dissenters > at that time as well but, IMHO, there were no substantive objections. > > > > > Then the issue comes into play about routers no longer > > having their supftware updated who IGNORE this bit > > once it is re-used. > > Unless they've implemented MOSPF for OSPFv3, they should not be using > any of the deprecated bits. If you know of any implementations, > please let us know. > > Thanks, > Acee > > > > > Mitchell Erblich > > ------------------ > > > > > > > > Acee Lindem wrote: > >> > >> Mitchell, > >> We've discussed this before (at least once). Nobody (to the best of > >> my knowledge) has implemented MOSPF for OSPFv3. If they have, they > >> should come forward with a complete specification since there were > >> things missing from RFC 2740 (e.g., the definition of the group > >> LSAs). > >> > >> Thanks, > >> Acee > >> On Aug 2, 2007, at 2:01 PM, Erblichs wrote: > >> > >>> Acee Lindem and group, > >>> > >>> IMO, OSPF needs to have some form > >>> of formal DEPRECATION policy. > >>> > >>> WOULD it be more prudent to suggest first > >>> generating some type of DEPRECATED statement? > >>> > >>> This is common in OSs when a feature is about > >>> to be removed in one of the next releases. > >>> Doing so ONLY in the context of a mail alias > >>> limits the notification to a limited audience. > >>> > >>> IMO, that COULD be done by checking the bit > >>> in the hello and if set generating the msg > >>> one time per intf. > >>> > >>> In theory, the DEPRECATE statement would suggest > >>> sending a email to the ospf@ietf.org mailing list > >>> identifying the manufacturer and the box in > >>> question. > >>> > >>> This could be done for 1 release time of say > >>> 6 months to VERIFY that no-one is using that > >>> bit.. > >>> > >>> Currently I believe the v3 spec says to ignore > >>> a capability bit that is not understood. So, it > >>> would quietly ignore if that bit is set. > >>> > >>> IFF this suggestion would be followed, then the > >>> appropriate sections within the RFC get changed > >>> to state that this item is being DEPRECATED, and > >>> that anyone wishing to notify of any possible > >>> conflict should send a email to the ospf@ietf.org > >>> mail alias. > >>> > >>> THis would cover ALL users who MIGHT be using > >>> a non-conformant and/or legacy (not currently in > >>> business) router and people who read the ospf RFCs > >>> but do not subscibe to the mail alias. > >>> > >>> In the legal sense, I believe this would be equal > >>> to "Due Diligence". > >>> > >>> Mitchell Erblich > >>> -------------------- > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Acee Lindem wrote: > >>>> > >>>> Hi Dan, > >>>> > >>>> On Aug 1, 2007, at 10:22 AM, Daniel Joyal wrote: > >>>> > >>>>> This also has an impact to the OSPFv3 MIB which has multicast- > >>>>> specific > >>>>> objects that would need to be removed. > >>>> > >>>> Yup. ospfv3MulticastExtensions and ospfv3IfMulticastForwarding > >>>> could > >>>> be removed. Anything else? > >>>> > >>>> Thanks, > >>>> Acee > >>>> > >>>>> > >>>>> -Dan > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Acee Lindem [mailto:acee@redback.com] > >>>>>> Sent: Tuesday, July 31, 2007 6:03 PM > >>>>>> To: OSPF List > >>>>>> Subject: [OSPF] Removal of MOSPF from OSPFv3 > >>>>>> > >>>>>> MOSPF has never really been fully specified in RFC 2740 and, > >>>>>> to the best of my knowledge, has never been implemented. > >>>>>> Hence, we again had some discussions about removing it from > >>>>>> the respin. I've made the changes but have not submitting > >>>>>> them. I've also attempted to reclaim the MC-bit in the prefix > >>>>>> options since this was never fully specified either and has > >>>>>> proved to be grossly inadequate to separate unicast and > >>>>>> multicast topologies. Please send comments ASAP. If I don't > >>>>>> hear any serious dissent I'll submit the update and we'll do > >>>>>> a quick re-WGLC. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> > >>>>>> *************** > >>>>>> *** 82,89 **** > >>>>>> addition, option handling has been made more flexible. > >>>>>> > >>>>>> All of OSPF for IPv4's optional capabilities, including > >>>>>> demand > >>>>>> ! circuit support, Not-So-Stubby Areas (NSSAs), and the > >>>>>> multicast > >>>>>> ! extensions to OSPF (MOSPF) are also supported in OSPF for > >>>>>> IPv6. > >>>>>> > >>>>>> > >>>>>> > >>>>>> --- 82,89 ---- > >>>>>> addition, option handling has been made more flexible. > >>>>>> > >>>>>> All of OSPF for IPv4's optional capabilities, including > >>>>>> demand > >>>>>> ! circuit support and Not-So-Stubby Areas (NSSAs) are also > >>>>>> supported in > >>>>>> ! OSPF for IPv6. > >>>>>> > >>>>>> > >>>>>> > >>>>>> *************** > >>>>>> *** 828,844 **** > >>>>>> LSAs, network-LSAs, inter-area-prefix-LSAs, > >>>>>> inter-area-router- LSAs, > >>>>>> and intra-area-prefix-LSAs. LSAs with unknown LS type, > >>>>>> U-bit set to > >>>>>> 1 (flood even when unrecognized) and area scope also > >>>>>> appear in the > >>>>>> ! area data structure. IPv6 routers implementing MOSPF add > >>>>>> group- > >>>>>> ! membership-LSAs to the area data structure. NSSA-LSAs are > >>>>>> also > >>>>>> ! included in an NSSA area's data structure. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 15] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> 3.1.2. The Interface Data structure > >>>>>> --- 828,844 ---- > >>>>>> LSAs, network-LSAs, inter-area-prefix-LSAs, > >>>>>> inter-area-router- LSAs, > >>>>>> and intra-area-prefix-LSAs. LSAs with unknown LS type, > >>>>>> U-bit set to > >>>>>> 1 (flood even when unrecognized) and area scope also > >>>>>> appear in the > >>>>>> ! area data structure. NSSA-LSAs are also included in an > >>>>>> NSSA area's > >>>>>> ! data structure. > >>>>>> ! > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 15] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> 3.1.2. The Interface Data structure > >>>>>> *************** > >>>>>> *** 1086,1094 **** > >>>>>> o The Options field within Database Description > >>>>>> packets has moved > >>>>>> around, getting larger in the process. More options > >>>>>> bits are now > >>>>>> possible. Those that MUST be set correctly in Database > >>>>>> ! Description packets are: The MC-bit is set if and only > >>>>>> if the > >>>>>> ! router is forwarding multicast datagrams according to > >>>>>> the MOSPF > >>>>>> ! specification in [MOSPF], and the DC-bit is set if and > >>>>>> only > >>>>>> if the > >>>>>> router wishes to suppress the sending of Hellos over > >>>>>> the interface > >>>>>> (see [DEMAND]). Unrecognized bits in the Database > >>>>>> Description > >>>>>> packet's Options field should be cleared. > >>>>>> --- 1086,1092 ---- > >>>>>> o The Options field within Database Description > >>>>>> packets has moved > >>>>>> around, getting larger in the process. More options > >>>>>> bits are now > >>>>>> possible. Those that MUST be set correctly in Database > >>>>>> ! Description packets are: The DC-bit is set if and only > >>>>>> if the > >>>>>> router wishes to suppress the sending of Hellos over > >>>>>> the interface > >>>>>> (see [DEMAND]). Unrecognized bits in the Database > >>>>>> Description > >>>>>> packet's Options field should be cleared. > >>>>>> *************** > >>>>>> *** 1577,1591 **** > >>>>>> should be set unless the router will not participate in > >>>>>> transit > >>>>>> IPv6 > >>>>>> routing. The E-bit should be clear if and only if the > >>>>>> attached area > >>>>>> is an OSPF stub or OSPF NSSA area. The E-bit should > >>>>>> always be set in > >>>>>> ! AS scoped LSAs. The MC-bit should be set if and only if > >>>>>> the router > >>>>>> ! is running MOSPF and the LSA is to be used in the multicast > >>>>>> SPF > >>>>>> ! computation (see [MOSPF]). The N-bit should be set if > >>>>>> and only if > >>>>>> ! the attached area is an OSPF NSSA area. The R-bit should > >>>>>> be set > >>>>>> ! unless the router will not participate in any transit > >>>>>> routing. The > >>>>>> ! DC-bit should be set if and only if the router can correctly > >>>>>> process > >>>>>> ! the DoNotAge bit when it appears in the LS age field of LSAs > >>>>>> (see > >>>>>> ! [DEMAND]). All unrecognized bits in the Options field > >>>>>> should be > >>>>>> ! cleared. > >>>>>> > >>>>>> The V6-bit and R-bit are only examined in Router-LSAs > >>>>>> during the SPF > >>>>>> computation. In other LSA types containing options, > >>>>>> they are set for > >>>>>> --- 1577,1588 ---- > >>>>>> should be set unless the router will not participate in > >>>>>> transit > >>>>>> IPv6 > >>>>>> routing. The E-bit should be clear if and only if the > >>>>>> attached area > >>>>>> is an OSPF stub or OSPF NSSA area. The E-bit should > >>>>>> always be set in > >>>>>> ! AS scoped LSAs. The N-bit should be set if and only if the > >>>>>> attached > >>>>>> ! area is an OSPF NSSA area. The R-bit should be set > >>>>>> unless the > >>>>>> router > >>>>>> ! will not participate in any transit routing. The DC-bit > >>>>>> should be > >>>>>> ! set if and only if the router can correctly process the > >>>>>> DoNotAge > >>>>>> bit > >>>>>> ! when it appears in the LS age field of LSAs (see > >>>>>> [DEMAND]). All > >>>>>> ! unrecognized bits in the Options field should be cleared. > >>>>>> > >>>>>> The V6-bit and R-bit are only examined in Router-LSAs > >>>>>> during the SPF > >>>>>> computation. In other LSA types containing options, > >>>>>> they are set for > >>>>>> *************** > >>>>>> *** 1603,1610 **** > >>>>>> State ID fields. > >>>>>> > >>>>>> To the left of the Options field, the router capability > >>>>>> bits V, E, > >>>>>> ! and B should be set according to Section 12.4.1 of > >>>>>> [OSPFV2]. Bit W > >>>>>> ! should be coded according to [MOSPF]. > >>>>>> > >>>>>> Each of the router's interfaces to the area are then > >>>>>> described by > >>>>>> appending "link descriptions" to the router-LSA. Each link > >>>>>> --- 1600,1606 ---- > >>>>>> State ID fields. > >>>>>> > >>>>>> To the left of the Options field, the router capability > >>>>>> bits V, E, > >>>>>> ! and B should be set according to Section 12.4.1 of [OSPFV2]. > >>>>>> > >>>>>> Each of the router's interfaces to the area are then > >>>>>> described by > >>>>>> appending "link descriptions" to the router-LSA. Each link > >>>>>> *************** > >>>>>> *** 1732,1748 **** > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 31] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> Designated Router. > >>>>>> > >>>>>> o The Options field in the network-LSA is set to the > >>>>>> logical OR of > >>>>>> the Options fields contained within the link's > >>>>>> associated link- > >>>>>> ! LSAs. In this way, the network link exhibits a > >>>>>> capability > >>>>>> when at > >>>>>> ! least one of the link's routers requests that the > >>>>>> capability be > >>>>>> advertised. > >>>>>> > >>>>>> As an example, assuming that Router RT4 has been > >>>>>> elected Designated > >>>>>> --- 1732,1749 ---- > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 31] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> Designated Router. > >>>>>> > >>>>>> o The Options field in the network-LSA is set to the > >>>>>> logical OR of > >>>>>> the Options fields contained within the link's > >>>>>> associated link- > >>>>>> ! LSAs corresponding to fully adjacent neighbors. In > >>>>>> this way, > >>>>>> the > >>>>>> ! network link exhibits a capability when at least one > >>>>>> fully > >>>>>> ! adjacent neighbor on the link requests that the > >>>>>> capability be > >>>>>> advertised. > >>>>>> > >>>>>> As an example, assuming that Router RT4 has been > >>>>>> elected Designated > >>>>>> *************** > >>>>>> *** 1787,1801 **** > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 32] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be > >>>>>> clear. The > >>>>>> coding > >>>>>> ! of the MC-bit depends upon whether, and if so how, > >>>>>> MOSPF is > >>>>>> ! operating in the routing domain (see [MOSPF]). > >>>>>> > >>>>>> o Link-local addresses MUST never be advertised in inter- > >>>>>> area- > >>>>>> prefix-LSAs. > >>>>>> --- 1788,1799 ---- > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 32] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be clear. > >>>>>> > >>>>>> o Link-local addresses MUST never be advertised in inter- > >>>>>> area- > >>>>>> prefix-LSAs. > >>>>>> *************** > >>>>>> *** 1894,1916 **** > >>>>>> Address Prefix fields embedded within the LSA body. > >>>>>> Network Mask > >>>>>> is no longer specified. > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be > >>>>>> clear. The > >>>>>> coding > >>>>>> ! of the MC-bit depends upon whether, and if so how, > >>>>>> MOSPF is > >>>>>> ! operating in the routing domain (see [MOSPF]). > >>>>>> ! > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> - Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 34] > >>>>>> - > >>>>>> > >>>>>> - Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> ! o Link-local addresses can never be advertised in AS- > >>>>>> external- > >>>>>> LSAs. > >>>>>> > >>>>>> - o The forwarding address is present in the > >>>>>> AS-external-LSA if and > >>>>>> - only if the AS-external-LSA's bit F is set. > >>>>>> > >>>>>> o The external route tag is present in the > >>>>>> AS-external-LSA if and > >>>>>> only if the AS-external-LSA's bit T is set. > >>>>>> --- 1892,1911 ---- > >>>>>> Address Prefix fields embedded within the LSA body. > >>>>>> Network Mask > >>>>>> is no longer specified. > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be clear. > >>>>>> > >>>>>> + o Link-local addresses can never be advertised in AS- > >>>>>> external- > >>>>>> LSAs. > >>>>>> > >>>>>> + o The forwarding address is present in the > >>>>>> AS-external-LSA if and > >>>>>> + only if the AS-external-LSA's bit F is set. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 34] > >>>>>> ! > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> o The external route tag is present in the > >>>>>> AS-external-LSA if and > >>>>>> only if the AS-external-LSA's bit T is set. > >>>>>> *************** > >>>>>> *** 1982,1990 **** > >>>>>> Address Prefix fields embedded within the LSA body. > >>>>>> Network > >>>>>> Mask > >>>>>> is no longer specified. > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be > >>>>>> clear. The > >>>>>> coding > >>>>>> ! of the MC-bit depends upon whether, and if so how, > >>>>>> MOSPF is > >>>>>> ! operating in the routing domain (see [MOSPF]). > >>>>>> > >>>>>> o Link-local addresses can never be advertised in NSSA- > >>>>>> LSAs. > >>>>>> > >>>>>> --- 1971,1977 ---- > >>>>>> Address Prefix fields embedded within the LSA body. > >>>>>> Network > >>>>>> Mask > >>>>>> is no longer specified. > >>>>>> > >>>>>> ! o The NU-bit in the PrefixOptions field should be clear. > >>>>>> > >>>>>> o Link-local addresses can never be advertised in NSSA- > >>>>>> LSAs. > >>>>>> > >>>>>> *************** > >>>>>> *** 2450,2475 **** > >>>>>> area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), > >>>>>> NSSA-LSAs > >>>>>> (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), > >>>>>> and > >>>>>> Intra- > >>>>>> Area-Prefix-LSAs (0x2009) are assumed to be understood > >>>>>> by all > >>>>>> ! routers. However, not all LS types are understood by > >>>>>> all routers, > >>>>>> ! For example, the group-membership-LSA (0x2006) is understood > >>>>>> only by > >>>>>> ! MOSPF routers and since it has its U-bit set to 0. This LS > >>>>>> Type > >>>>>> ! should only be flooded to a non-MOSPF neighbor > >>>>>> (determined by > >>>>>> ! examining the MC-bit in the neighbor's Database Description > >>>>>> packets' > >>>>>> ! Options field) when the neighbor is Designated Router or > >>>>>> Backup > >>>>>> ! Designated Router for the attached link. > >>>>>> ! > >>>>>> ! The previous paragraph solves a problem for IPv4 OSPF > >>>>>> extensions > >>>>>> such > >>>>>> ! > >>>>>> ! > >>>>>> ! > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 44] > >>>>>> ! > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> ! > >>>>>> ! > >>>>>> ! as MOSPF, which require that the Designated Router > >>>>>> support the > >>>>>> ! extension in order to have the new LSA types flooded across > >>>>>> broadcast > >>>>>> ! and NBMA networks (see Section 10.2 of [MOSPF]). > >>>>>> > >>>>>> 3.5.3. Installing LSAs in the database > >>>>>> > >>>>>> --- 2422,2436 ---- > >>>>>> area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), > >>>>>> NSSA-LSAs > >>>>>> (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), > >>>>>> and > >>>>>> Intra- > >>>>>> Area-Prefix-LSAs (0x2009) are assumed to be understood > >>>>>> by all > >>>>>> ! routers. However, all LS types MAY not be understood by all > >>>>>> routers. > >>>>>> ! For example, a new LSA type with its U-bit set to 0 MAY > >>>>>> only be > >>>>>> ! understood by a subset of routers. This new LS Type > >>>>>> should only be > >>>>>> ! flooded to an OSPF neighbor that understands the LS type > >>>>>> or when > >>>>>> the > >>>>>> ! neighbor that doesn't understand it is Designated Router > >>>>>> or Backup > >>>>>> ! Designated Router for the attached link. This allows > >>>>>> the LSA to be > >>>>>> ! flooded on the local link even if either the router elected > >>>>>> ! Designated Router or Backup Designated Router doesn't > >>>>>> understand > >>>>>> the > >>>>>> ! LS type. > >>>>>> > >>>>>> 3.5.3. Installing LSAs in the database > >>>>>> > >>>>>> *************** > >>>>>> *** 3395,3406 **** > >>>>>> neighbor relationships from forming (e.g., the E-bit > >>>>>> below); these > >>>>>> mismatches are discovered through the sending and > >>>>>> receiving of > >>>>>> Hello > >>>>>> packets. Some option mismatches prevent particular LSA > >>>>>> types from > >>>>>> ! being flooded across adjacencies (e.g., the MC-bit > >>>>>> below); these > >>>>>> are > >>>>>> ! discovered through the sending and receiving of Database > >>>>>> Description > >>>>>> ! packets. Some option mismatches prevent routers from being > >>>>>> included > >>>>>> ! in one or more of the various routing calculations > >>>>>> because of their > >>>>>> ! reduced functionality (again, the MC-bit is an example); > >>>>>> these > >>>>>> ! mismatches are discovered by examining LSAs. > >>>>>> > >>>>>> Seven bits of the OSPF Options field have been assigned. > >>>>>> Each > >>>>>> bit is > >>>>>> described briefly below. Routers should reset (i.e., > >>>>>> clear) > >>>>>> --- 3395,3405 ---- > >>>>>> neighbor relationships from forming (e.g., the E-bit > >>>>>> below); these > >>>>>> mismatches are discovered through the sending and > >>>>>> receiving of > >>>>>> Hello > >>>>>> packets. Some option mismatches prevent particular LSA > >>>>>> types from > >>>>>> ! being flooded across adjacencies these are discovered > >>>>>> through > >>>>>> the > >>>>>> ! sending and receiving of Database Description packets. > >>>>>> Some option > >>>>>> ! mismatches prevent routers from being included in one or > >>>>>> more of > >>>>>> the > >>>>>> ! various routing calculations because of their reduced > >>>>>> functionality; > >>>>>> ! these mismatches are discovered by examining LSAs. > >>>>>> > >>>>>> Seven bits of the OSPF Options field have been assigned. > >>>>>> Each > >>>>>> bit is > >>>>>> described briefly below. Routers should reset (i.e., > >>>>>> clear) > >>>>>> *************** > >>>>>> *** 3414,3429 **** > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 61] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> 1 2 > >>>>>> ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > >>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+ > >>>>>> ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|MC| E|V6| > >>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+ > >>>>>> > >>>>>> The Options field > >>>>>> > >>>>>> --- 3413,3429 ---- > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 61] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> 1 2 > >>>>>> ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > >>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ > >>>>>> ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6| > >>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ > >>>>>> > >>>>>> The Options field > >>>>>> > >>>>>> *************** > >>>>>> *** 3438,3446 **** > >>>>>> This bit describes the way AS-external-LSAs are > >>>>>> flooded, as > >>>>>> described in Sections 3.6, 9.5, 10.8, and 12.1.2 of > >>>>>> [OSPFV2]. > >>>>>> > >>>>>> ! MC-bit > >>>>>> ! This bit describes whether IP multicast datagrams are > >>>>>> forwarded > >>>>>> ! according to the specifications in [MOSPF]. > >>>>>> > >>>>>> N-bit > >>>>>> This bit indicates whether or not the router is > >>>>>> attached to an > >>>>>> --- 3438,3447 ---- > >>>>>> This bit describes the way AS-external-LSAs are > >>>>>> flooded, as > >>>>>> described in Sections 3.6, 9.5, 10.8, and 12.1.2 of > >>>>>> [OSPFV2]. > >>>>>> > >>>>>> ! x-Bit > >>>>>> ! This bit was previously used by MOSPF (see [MOSPF]) > >>>>>> which has > >>>>>> been > >>>>>> ! deprecated for OSPFv3. It should be set to 0 and ignored > >>>>>> upon > >>>>>> ! reception. It may be reused in the future. > >>>>>> > >>>>>> N-bit > >>>>>> This bit indicates whether or not the router is > >>>>>> attached to an > >>>>>> *************** > >>>>>> *** 4021,4038 **** > >>>>>> cases or are to be marked as not readvertisable in others. > >>>>>> > >>>>>> 0 1 2 3 4 5 6 7 > >>>>>> ! +--+--+--+--+--+--+--+--+ > >>>>>> ! | | | |DN| P|MC|LA|NU| > >>>>>> ! +--+--+--+--+--+--+--+--+ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 72] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> The Prefix Options field > >>>>>> --- 4021,4038 ---- > >>>>>> cases or are to be marked as not readvertisable in others. > >>>>>> > >>>>>> 0 1 2 3 4 5 6 7 > >>>>>> ! +--+--+--+--+--+-+--+--+ > >>>>>> ! | | | |DN| P|x|LA|NU| > >>>>>> ! +--+--+--+--+--+-+--+--+ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 72] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> The Prefix Options field > >>>>>> *************** > >>>>>> *** 4050,4059 **** > >>>>>> Section 3.4.3.9. An implementation MAY also set the > >>>>>> LA-bit for > >>>>>> prefixes advertised with a host PrefixLength (128). > >>>>>> > >>>>>> ! MC-bit > >>>>>> ! The "multicast" capability bit. If set, the prefix > >>>>>> should be > >>>>>> ! included in IPv6 multicast routing calculations. If > >>>>>> not set, it > >>>>>> ! should be excluded. > >>>>>> > >>>>>> P-bit > >>>>>> The "propagate" bit. Set on NSSA area prefixes that > >>>>>> should be > >>>>>> --- 4050,4060 ---- > >>>>>> Section 3.4.3.9. An implementation MAY also set the > >>>>>> LA-bit for > >>>>>> prefixes advertised with a host PrefixLength (128). > >>>>>> > >>>>>> ! x-bit > >>>>>> ! This bit was previously defined as a "multicast" > >>>>>> capability bit. > >>>>>> ! However, the use was never adequately specified and > >>>>>> it is being > >>>>>> ! deprecated. It is set to 0 and ignored upon > >>>>>> reception. It > >>>>>> may be > >>>>>> ! reused in the future. > >>>>>> > >>>>>> P-bit > >>>>>> The "propagate" bit. Set on NSSA area prefixes that > >>>>>> should be > >>>>>> *************** > >>>>>> *** 4193,4209 **** > >>>>>> > >>>>>> The LSA function codes are defined as follows. The > >>>>>> origination > >>>>>> and > >>>>>> processing of these LSA function codes are defined > >>>>>> elsewhere in > >>>>>> this > >>>>>> ! document, except for the group-membership-LSA (see > >>>>>> [MOSPF]) and the > >>>>>> ! NSSA-LSA (see [NSSA]). As shown below, each LSA > >>>>>> function code also > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires November 12, 2007 > >>>>>> [Page 75] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> May > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> ! implies a specific setting for the U, S1, and S2 bits. > >>>>>> > >>>>>> > >>>>>> LSA function code LS Type Description > >>>>>> --- 4193,4210 ---- > >>>>>> > >>>>>> The LSA function codes are defined as follows. The > >>>>>> origination > >>>>>> and > >>>>>> processing of these LSA function codes are defined > >>>>>> elsewhere in > >>>>>> this > >>>>>> ! document, except for the NSSA-LSA (see [NSSA]) and > >>>>>> 0x2006 which was > >>>>>> ! previously used by MOSPF (see [MOSPF]). MOSPF has been > >>>>>> deprecated > >>>>>> > >>>>>> > >>>>>> > >>>>>> ! Coltun, et al. Expires February 2, 2008 > >>>>>> [Page 75] > >>>>>> > >>>>>> > >>>>>> ! Internet-Draft OSPF for IPv6 > >>>>>> August > >>>>>> 2007 > >>>>>> > >>>>>> > >>>>>> ! f _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Mar 9 03:56:00 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 AE7123A67D2; Sun, 9 Mar 2008 03:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.491 X-Spam-Level: X-Spam-Status: No, score=-100.491 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 mTgg9LufxhvV; Sun, 9 Mar 2008 03:55:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37ED528C114; Sun, 9 Mar 2008 03:55:58 -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 B31443A67D2 for ; Sun, 9 Mar 2008 03:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 KebYBqQhCSKh for ; Sun, 9 Mar 2008 03:55:54 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 610623A6B23 for ; Sun, 9 Mar 2008 03:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6CA0E9235A2; Sun, 9 Mar 2008 03:53:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15173-06; Sun, 9 Mar 2008 03:53:33 -0700 (PDT) Received: from [ZK?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 82DBC9235A1; Sun, 9 Mar 2008 03:53:32 -0700 (PDT) In-Reply-To: <46B36948.9E7A1BD0@earthlink.net> References: <66A3A59B-F3DA-437C-9107-67C36A4B93F7@redback.com> <4B7DAC3FEFD35D4A96BDD011699050140A4245F9@zrtphxm1.corp.nortel.com> <93E269EB-87EB-4B6F-B212-B3E15C049B55@redback.com> <46B21BEF.F72A2FB2@earthlink.net> <46B25A86.72B967B9@earthlink.net> <46B36948.9E7A1BD0@earthlink.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <65F52DAF-CDA0-4AE9-9181-3FDD649A8719@redback.com> From: Acee Lindem Date: Sun, 9 Mar 2008 06:53:30 -0400 To: Erblichs X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] Removal of MOSPF from 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 Mitchell, The fact that the MOSPF bits and LSA types are specifically ignored doesn't constitute an implementation. Thanks, Acee On Aug 3, 2007, at 1:43 PM, Erblichs wrote: > Acee Lindem, > > What I am sure about MOSPF for OSPFv3. > > - Ethereal and other networking debuggers with different > versions identifyied this bit wrt MOSPF. > > - Almost all OSPFv3 versions have some type of support > to ignore the bit and the LSA type. Some of these > routers are from companies that no longer suport the > router or no longer exist. > > - Zebra and other public domain implementations had > at least 1 > > > > > Acee Lindem wrote: >> >> Mitchell, >> >> On Aug 2, 2007, at 6:28 PM, Erblichs wrote: >> >>> Yes Acee, I think we did, >>> >>> Are you 100% sure that NO-ONE generated a MOSPF >>> implimentation OR used it for something ELSE OR >>> if this bit is set is going to do WEIRD things. >>> If not then WHY NOT be as careful as possible? >> >> Again, this is MOSPF for OSPFv3. >> >>> >>> I just think that this isn't the ONLY thing in the >>> current or future that COULD/SHOULD be DEPRECATED. >>> >>> We could let a larger audience OUTSIDE of this >>> mail alias be AWARE that this/these things are intended >>> to be DEPRCATED/REMOVED. >>> >>> It has been around for years? >>> Document it for 6 months, and set a clock, and MAYBE >>> have implimentations check whether this bit is set? >>> However, this last bit introduces the chicken and >>> egg problem, That's why it needs to be a 1-time FYI >>> msg if generated. >>> >>> Then get rid of it... >> >> We'll re-WG last call the updated OSPFv3 document without the MOSPF >> for OSPFv3 extensions. Given that we've discussed this a number of >> times, this should be ample time. Here is a link to the initial E- >> mail in one such discussion: >> >> http://www1.ietf.org/mail-archive/web/ospf/current/msg03798.html >> >> This was more than 18 months ago. You were one of the main dissenters >> at that time as well but, IMHO, there were no substantive objections. >> >>> >>> Then the issue comes into play about routers no longer >>> having their supftware updated who IGNORE this bit >>> once it is re-used. >> >> Unless they've implemented MOSPF for OSPFv3, they should not be using >> any of the deprecated bits. If you know of any implementations, >> please let us know. >> >> Thanks, >> Acee >> >>> >>> Mitchell Erblich >>> ------------------ >>> >>> >>> >>> Acee Lindem wrote: >>>> >>>> Mitchell, >>>> We've discussed this before (at least once). Nobody (to the best of >>>> my knowledge) has implemented MOSPF for OSPFv3. If they have, they >>>> should come forward with a complete specification since there were >>>> things missing from RFC 2740 (e.g., the definition of the group >>>> LSAs). >>>> >>>> Thanks, >>>> Acee >>>> On Aug 2, 2007, at 2:01 PM, Erblichs wrote: >>>> >>>>> Acee Lindem and group, >>>>> >>>>> IMO, OSPF needs to have some form >>>>> of formal DEPRECATION policy. >>>>> >>>>> WOULD it be more prudent to suggest first >>>>> generating some type of DEPRECATED statement? >>>>> >>>>> This is common in OSs when a feature is about >>>>> to be removed in one of the next releases. >>>>> Doing so ONLY in the context of a mail alias >>>>> limits the notification to a limited audience. >>>>> >>>>> IMO, that COULD be done by checking the bit >>>>> in the hello and if set generating the msg >>>>> one time per intf. >>>>> >>>>> In theory, the DEPRECATE statement would suggest >>>>> sending a email to the ospf@ietf.org mailing list >>>>> identifying the manufacturer and the box in >>>>> question. >>>>> >>>>> This could be done for 1 release time of say >>>>> 6 months to VERIFY that no-one is using that >>>>> bit.. >>>>> >>>>> Currently I believe the v3 spec says to ignore >>>>> a capability bit that is not understood. So, it >>>>> would quietly ignore if that bit is set. >>>>> >>>>> IFF this suggestion would be followed, then the >>>>> appropriate sections within the RFC get changed >>>>> to state that this item is being DEPRECATED, and >>>>> that anyone wishing to notify of any possible >>>>> conflict should send a email to the ospf@ietf.org >>>>> mail alias. >>>>> >>>>> THis would cover ALL users who MIGHT be using >>>>> a non-conformant and/or legacy (not currently in >>>>> business) router and people who read the ospf RFCs >>>>> but do not subscibe to the mail alias. >>>>> >>>>> In the legal sense, I believe this would be equal >>>>> to "Due Diligence". >>>>> >>>>> Mitchell Erblich >>>>> -------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Acee Lindem wrote: >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> On Aug 1, 2007, at 10:22 AM, Daniel Joyal wrote: >>>>>> >>>>>>> This also has an impact to the OSPFv3 MIB which has multicast- >>>>>>> specific >>>>>>> objects that would need to be removed. >>>>>> >>>>>> Yup. ospfv3MulticastExtensions and ospfv3IfMulticastForwarding >>>>>> could >>>>>> be removed. Anything else? >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>>> >>>>>>> -Dan >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Acee Lindem [mailto:acee@redback.com] >>>>>>>> Sent: Tuesday, July 31, 2007 6:03 PM >>>>>>>> To: OSPF List >>>>>>>> Subject: [OSPF] Removal of MOSPF from OSPFv3 >>>>>>>> >>>>>>>> MOSPF has never really been fully specified in RFC 2740 and, >>>>>>>> to the best of my knowledge, has never been implemented. >>>>>>>> Hence, we again had some discussions about removing it from >>>>>>>> the respin. I've made the changes but have not submitting >>>>>>>> them. I've also attempted to reclaim the MC-bit in the prefix >>>>>>>> options since this was never fully specified either and has >>>>>>>> proved to be grossly inadequate to separate unicast and >>>>>>>> multicast topologies. Please send comments ASAP. If I don't >>>>>>>> hear any serious dissent I'll submit the update and we'll do >>>>>>>> a quick re-WGLC. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>>> >>>>>>>> *************** >>>>>>>> *** 82,89 **** >>>>>>>> addition, option handling has been made more flexible. >>>>>>>> >>>>>>>> All of OSPF for IPv4's optional capabilities, including >>>>>>>> demand >>>>>>>> ! circuit support, Not-So-Stubby Areas (NSSAs), and the >>>>>>>> multicast >>>>>>>> ! extensions to OSPF (MOSPF) are also supported in OSPF for >>>>>>>> IPv6. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- 82,89 ---- >>>>>>>> addition, option handling has been made more flexible. >>>>>>>> >>>>>>>> All of OSPF for IPv4's optional capabilities, including >>>>>>>> demand >>>>>>>> ! circuit support and Not-So-Stubby Areas (NSSAs) are also >>>>>>>> supported in >>>>>>>> ! OSPF for IPv6. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *************** >>>>>>>> *** 828,844 **** >>>>>>>> LSAs, network-LSAs, inter-area-prefix-LSAs, >>>>>>>> inter-area-router- LSAs, >>>>>>>> and intra-area-prefix-LSAs. LSAs with unknown LS type, >>>>>>>> U-bit set to >>>>>>>> 1 (flood even when unrecognized) and area scope also >>>>>>>> appear in the >>>>>>>> ! area data structure. IPv6 routers implementing MOSPF add >>>>>>>> group- >>>>>>>> ! membership-LSAs to the area data structure. NSSA-LSAs are >>>>>>>> also >>>>>>>> ! included in an NSSA area's data structure. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 15] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> 3.1.2. The Interface Data structure >>>>>>>> --- 828,844 ---- >>>>>>>> LSAs, network-LSAs, inter-area-prefix-LSAs, >>>>>>>> inter-area-router- LSAs, >>>>>>>> and intra-area-prefix-LSAs. LSAs with unknown LS type, >>>>>>>> U-bit set to >>>>>>>> 1 (flood even when unrecognized) and area scope also >>>>>>>> appear in the >>>>>>>> ! area data structure. NSSA-LSAs are also included in an >>>>>>>> NSSA area's >>>>>>>> ! data structure. >>>>>>>> ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 15] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> 3.1.2. The Interface Data structure >>>>>>>> *************** >>>>>>>> *** 1086,1094 **** >>>>>>>> o The Options field within Database Description >>>>>>>> packets has moved >>>>>>>> around, getting larger in the process. More options >>>>>>>> bits are now >>>>>>>> possible. Those that MUST be set correctly in >>>>>>>> Database >>>>>>>> ! Description packets are: The MC-bit is set if and only >>>>>>>> if the >>>>>>>> ! router is forwarding multicast datagrams according to >>>>>>>> the MOSPF >>>>>>>> ! specification in [MOSPF], and the DC-bit is set if and >>>>>>>> only >>>>>>>> if the >>>>>>>> router wishes to suppress the sending of Hellos over >>>>>>>> the interface >>>>>>>> (see [DEMAND]). Unrecognized bits in the Database >>>>>>>> Description >>>>>>>> packet's Options field should be cleared. >>>>>>>> --- 1086,1092 ---- >>>>>>>> o The Options field within Database Description >>>>>>>> packets has moved >>>>>>>> around, getting larger in the process. More options >>>>>>>> bits are now >>>>>>>> possible. Those that MUST be set correctly in >>>>>>>> Database >>>>>>>> ! Description packets are: The DC-bit is set if and only >>>>>>>> if the >>>>>>>> router wishes to suppress the sending of Hellos over >>>>>>>> the interface >>>>>>>> (see [DEMAND]). Unrecognized bits in the Database >>>>>>>> Description >>>>>>>> packet's Options field should be cleared. >>>>>>>> *************** >>>>>>>> *** 1577,1591 **** >>>>>>>> should be set unless the router will not participate in >>>>>>>> transit >>>>>>>> IPv6 >>>>>>>> routing. The E-bit should be clear if and only if the >>>>>>>> attached area >>>>>>>> is an OSPF stub or OSPF NSSA area. The E-bit should >>>>>>>> always be set in >>>>>>>> ! AS scoped LSAs. The MC-bit should be set if and only if >>>>>>>> the router >>>>>>>> ! is running MOSPF and the LSA is to be used in the >>>>>>>> multicast >>>>>>>> SPF >>>>>>>> ! computation (see [MOSPF]). The N-bit should be set if >>>>>>>> and only if >>>>>>>> ! the attached area is an OSPF NSSA area. The R-bit should >>>>>>>> be set >>>>>>>> ! unless the router will not participate in any transit >>>>>>>> routing. The >>>>>>>> ! DC-bit should be set if and only if the router can >>>>>>>> correctly >>>>>>>> process >>>>>>>> ! the DoNotAge bit when it appears in the LS age field of >>>>>>>> LSAs >>>>>>>> (see >>>>>>>> ! [DEMAND]). All unrecognized bits in the Options field >>>>>>>> should be >>>>>>>> ! cleared. >>>>>>>> >>>>>>>> The V6-bit and R-bit are only examined in Router-LSAs >>>>>>>> during the SPF >>>>>>>> computation. In other LSA types containing options, >>>>>>>> they are set for >>>>>>>> --- 1577,1588 ---- >>>>>>>> should be set unless the router will not participate in >>>>>>>> transit >>>>>>>> IPv6 >>>>>>>> routing. The E-bit should be clear if and only if the >>>>>>>> attached area >>>>>>>> is an OSPF stub or OSPF NSSA area. The E-bit should >>>>>>>> always be set in >>>>>>>> ! AS scoped LSAs. The N-bit should be set if and only if >>>>>>>> the >>>>>>>> attached >>>>>>>> ! area is an OSPF NSSA area. The R-bit should be set >>>>>>>> unless the >>>>>>>> router >>>>>>>> ! will not participate in any transit routing. The DC-bit >>>>>>>> should be >>>>>>>> ! set if and only if the router can correctly process the >>>>>>>> DoNotAge >>>>>>>> bit >>>>>>>> ! when it appears in the LS age field of LSAs (see >>>>>>>> [DEMAND]). All >>>>>>>> ! unrecognized bits in the Options field should be cleared. >>>>>>>> >>>>>>>> The V6-bit and R-bit are only examined in Router-LSAs >>>>>>>> during the SPF >>>>>>>> computation. In other LSA types containing options, >>>>>>>> they are set for >>>>>>>> *************** >>>>>>>> *** 1603,1610 **** >>>>>>>> State ID fields. >>>>>>>> >>>>>>>> To the left of the Options field, the router capability >>>>>>>> bits V, E, >>>>>>>> ! and B should be set according to Section 12.4.1 of >>>>>>>> [OSPFV2]. Bit W >>>>>>>> ! should be coded according to [MOSPF]. >>>>>>>> >>>>>>>> Each of the router's interfaces to the area are then >>>>>>>> described by >>>>>>>> appending "link descriptions" to the router-LSA. Each >>>>>>>> link >>>>>>>> --- 1600,1606 ---- >>>>>>>> State ID fields. >>>>>>>> >>>>>>>> To the left of the Options field, the router capability >>>>>>>> bits V, E, >>>>>>>> ! and B should be set according to Section 12.4.1 of >>>>>>>> [OSPFV2]. >>>>>>>> >>>>>>>> Each of the router's interfaces to the area are then >>>>>>>> described by >>>>>>>> appending "link descriptions" to the router-LSA. Each >>>>>>>> link >>>>>>>> *************** >>>>>>>> *** 1732,1748 **** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 31] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> Designated Router. >>>>>>>> >>>>>>>> o The Options field in the network-LSA is set to the >>>>>>>> logical OR of >>>>>>>> the Options fields contained within the link's >>>>>>>> associated link- >>>>>>>> ! LSAs. In this way, the network link exhibits a >>>>>>>> capability >>>>>>>> when at >>>>>>>> ! least one of the link's routers requests that the >>>>>>>> capability be >>>>>>>> advertised. >>>>>>>> >>>>>>>> As an example, assuming that Router RT4 has been >>>>>>>> elected Designated >>>>>>>> --- 1732,1749 ---- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 31] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> Designated Router. >>>>>>>> >>>>>>>> o The Options field in the network-LSA is set to the >>>>>>>> logical OR of >>>>>>>> the Options fields contained within the link's >>>>>>>> associated link- >>>>>>>> ! LSAs corresponding to fully adjacent neighbors. In >>>>>>>> this way, >>>>>>>> the >>>>>>>> ! network link exhibits a capability when at least one >>>>>>>> fully >>>>>>>> ! adjacent neighbor on the link requests that the >>>>>>>> capability be >>>>>>>> advertised. >>>>>>>> >>>>>>>> As an example, assuming that Router RT4 has been >>>>>>>> elected Designated >>>>>>>> *************** >>>>>>>> *** 1787,1801 **** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 32] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be >>>>>>>> clear. The >>>>>>>> coding >>>>>>>> ! of the MC-bit depends upon whether, and if so how, >>>>>>>> MOSPF is >>>>>>>> ! operating in the routing domain (see [MOSPF]). >>>>>>>> >>>>>>>> o Link-local addresses MUST never be advertised in >>>>>>>> inter- >>>>>>>> area- >>>>>>>> prefix-LSAs. >>>>>>>> --- 1788,1799 ---- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 32] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be clear. >>>>>>>> >>>>>>>> o Link-local addresses MUST never be advertised in >>>>>>>> inter- >>>>>>>> area- >>>>>>>> prefix-LSAs. >>>>>>>> *************** >>>>>>>> *** 1894,1916 **** >>>>>>>> Address Prefix fields embedded within the LSA body. >>>>>>>> Network Mask >>>>>>>> is no longer specified. >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be >>>>>>>> clear. The >>>>>>>> coding >>>>>>>> ! of the MC-bit depends upon whether, and if so how, >>>>>>>> MOSPF is >>>>>>>> ! operating in the routing domain (see [MOSPF]). >>>>>>>> ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 34] >>>>>>>> - >>>>>>>> >>>>>>>> - Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> ! o Link-local addresses can never be advertised in AS- >>>>>>>> external- >>>>>>>> LSAs. >>>>>>>> >>>>>>>> - o The forwarding address is present in the >>>>>>>> AS-external-LSA if and >>>>>>>> - only if the AS-external-LSA's bit F is set. >>>>>>>> >>>>>>>> o The external route tag is present in the >>>>>>>> AS-external-LSA if and >>>>>>>> only if the AS-external-LSA's bit T is set. >>>>>>>> --- 1892,1911 ---- >>>>>>>> Address Prefix fields embedded within the LSA body. >>>>>>>> Network Mask >>>>>>>> is no longer specified. >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be clear. >>>>>>>> >>>>>>>> + o Link-local addresses can never be advertised in AS- >>>>>>>> external- >>>>>>>> LSAs. >>>>>>>> >>>>>>>> + o The forwarding address is present in the >>>>>>>> AS-external-LSA if and >>>>>>>> + only if the AS-external-LSA's bit F is set. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 34] >>>>>>>> ! >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> o The external route tag is present in the >>>>>>>> AS-external-LSA if and >>>>>>>> only if the AS-external-LSA's bit T is set. >>>>>>>> *************** >>>>>>>> *** 1982,1990 **** >>>>>>>> Address Prefix fields embedded within the LSA body. >>>>>>>> Network >>>>>>>> Mask >>>>>>>> is no longer specified. >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be >>>>>>>> clear. The >>>>>>>> coding >>>>>>>> ! of the MC-bit depends upon whether, and if so how, >>>>>>>> MOSPF is >>>>>>>> ! operating in the routing domain (see [MOSPF]). >>>>>>>> >>>>>>>> o Link-local addresses can never be advertised in NSSA- >>>>>>>> LSAs. >>>>>>>> >>>>>>>> --- 1971,1977 ---- >>>>>>>> Address Prefix fields embedded within the LSA body. >>>>>>>> Network >>>>>>>> Mask >>>>>>>> is no longer specified. >>>>>>>> >>>>>>>> ! o The NU-bit in the PrefixOptions field should be clear. >>>>>>>> >>>>>>>> o Link-local addresses can never be advertised in NSSA- >>>>>>>> LSAs. >>>>>>>> >>>>>>>> *************** >>>>>>>> *** 2450,2475 **** >>>>>>>> area-prefix-LSAs (0x2003), inter-area-router-LSAs >>>>>>>> (0x2004), >>>>>>>> NSSA-LSAs >>>>>>>> (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), >>>>>>>> and >>>>>>>> Intra- >>>>>>>> Area-Prefix-LSAs (0x2009) are assumed to be understood >>>>>>>> by all >>>>>>>> ! routers. However, not all LS types are understood by >>>>>>>> all routers, >>>>>>>> ! For example, the group-membership-LSA (0x2006) is >>>>>>>> understood >>>>>>>> only by >>>>>>>> ! MOSPF routers and since it has its U-bit set to 0. >>>>>>>> This LS >>>>>>>> Type >>>>>>>> ! should only be flooded to a non-MOSPF neighbor >>>>>>>> (determined by >>>>>>>> ! examining the MC-bit in the neighbor's Database >>>>>>>> Description >>>>>>>> packets' >>>>>>>> ! Options field) when the neighbor is Designated Router or >>>>>>>> Backup >>>>>>>> ! Designated Router for the attached link. >>>>>>>> ! >>>>>>>> ! The previous paragraph solves a problem for IPv4 OSPF >>>>>>>> extensions >>>>>>>> such >>>>>>>> ! >>>>>>>> ! >>>>>>>> ! >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 44] >>>>>>>> ! >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> ! >>>>>>>> ! >>>>>>>> ! as MOSPF, which require that the Designated Router >>>>>>>> support the >>>>>>>> ! extension in order to have the new LSA types flooded >>>>>>>> across >>>>>>>> broadcast >>>>>>>> ! and NBMA networks (see Section 10.2 of [MOSPF]). >>>>>>>> >>>>>>>> 3.5.3. Installing LSAs in the database >>>>>>>> >>>>>>>> --- 2422,2436 ---- >>>>>>>> area-prefix-LSAs (0x2003), inter-area-router-LSAs >>>>>>>> (0x2004), >>>>>>>> NSSA-LSAs >>>>>>>> (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), >>>>>>>> and >>>>>>>> Intra- >>>>>>>> Area-Prefix-LSAs (0x2009) are assumed to be understood >>>>>>>> by all >>>>>>>> ! routers. However, all LS types MAY not be understood >>>>>>>> by all >>>>>>>> routers. >>>>>>>> ! For example, a new LSA type with its U-bit set to 0 MAY >>>>>>>> only be >>>>>>>> ! understood by a subset of routers. This new LS Type >>>>>>>> should only be >>>>>>>> ! flooded to an OSPF neighbor that understands the LS type >>>>>>>> or when >>>>>>>> the >>>>>>>> ! neighbor that doesn't understand it is Designated Router >>>>>>>> or Backup >>>>>>>> ! Designated Router for the attached link. This allows >>>>>>>> the LSA to be >>>>>>>> ! flooded on the local link even if either the router >>>>>>>> elected >>>>>>>> ! Designated Router or Backup Designated Router doesn't >>>>>>>> understand >>>>>>>> the >>>>>>>> ! LS type. >>>>>>>> >>>>>>>> 3.5.3. Installing LSAs in the database >>>>>>>> >>>>>>>> *************** >>>>>>>> *** 3395,3406 **** >>>>>>>> neighbor relationships from forming (e.g., the E-bit >>>>>>>> below); these >>>>>>>> mismatches are discovered through the sending and >>>>>>>> receiving of >>>>>>>> Hello >>>>>>>> packets. Some option mismatches prevent particular LSA >>>>>>>> types from >>>>>>>> ! being flooded across adjacencies (e.g., the MC-bit >>>>>>>> below); these >>>>>>>> are >>>>>>>> ! discovered through the sending and receiving of Database >>>>>>>> Description >>>>>>>> ! packets. Some option mismatches prevent routers from >>>>>>>> being >>>>>>>> included >>>>>>>> ! in one or more of the various routing calculations >>>>>>>> because of their >>>>>>>> ! reduced functionality (again, the MC-bit is an example); >>>>>>>> these >>>>>>>> ! mismatches are discovered by examining LSAs. >>>>>>>> >>>>>>>> Seven bits of the OSPF Options field have been assigned. >>>>>>>> Each >>>>>>>> bit is >>>>>>>> described briefly below. Routers should reset (i.e., >>>>>>>> clear) >>>>>>>> --- 3395,3405 ---- >>>>>>>> neighbor relationships from forming (e.g., the E-bit >>>>>>>> below); these >>>>>>>> mismatches are discovered through the sending and >>>>>>>> receiving of >>>>>>>> Hello >>>>>>>> packets. Some option mismatches prevent particular LSA >>>>>>>> types from >>>>>>>> ! being flooded across adjacencies these are discovered >>>>>>>> through >>>>>>>> the >>>>>>>> ! sending and receiving of Database Description packets. >>>>>>>> Some option >>>>>>>> ! mismatches prevent routers from being included in one or >>>>>>>> more of >>>>>>>> the >>>>>>>> ! various routing calculations because of their reduced >>>>>>>> functionality; >>>>>>>> ! these mismatches are discovered by examining LSAs. >>>>>>>> >>>>>>>> Seven bits of the OSPF Options field have been assigned. >>>>>>>> Each >>>>>>>> bit is >>>>>>>> described briefly below. Routers should reset (i.e., >>>>>>>> clear) >>>>>>>> *************** >>>>>>>> *** 3414,3429 **** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 61] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> 1 2 >>>>>>>> ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>>> 2 3 >>>>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-- >>>>>>>> +--+ >>>>>>>> ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|MC| >>>>>>>> E|V6| >>>>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-- >>>>>>>> +--+ >>>>>>>> >>>>>>>> The Options field >>>>>>>> >>>>>>>> --- 3413,3429 ---- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 61] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> 1 2 >>>>>>>> ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >>>>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-- >>>>>>>> +--+ >>>>>>>> ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E| >>>>>>>> V6| >>>>>>>> ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-- >>>>>>>> +--+ >>>>>>>> >>>>>>>> The Options field >>>>>>>> >>>>>>>> *************** >>>>>>>> *** 3438,3446 **** >>>>>>>> This bit describes the way AS-external-LSAs are >>>>>>>> flooded, as >>>>>>>> described in Sections 3.6, 9.5, 10.8, and 12.1.2 of >>>>>>>> [OSPFV2]. >>>>>>>> >>>>>>>> ! MC-bit >>>>>>>> ! This bit describes whether IP multicast datagrams are >>>>>>>> forwarded >>>>>>>> ! according to the specifications in [MOSPF]. >>>>>>>> >>>>>>>> N-bit >>>>>>>> This bit indicates whether or not the router is >>>>>>>> attached to an >>>>>>>> --- 3438,3447 ---- >>>>>>>> This bit describes the way AS-external-LSAs are >>>>>>>> flooded, as >>>>>>>> described in Sections 3.6, 9.5, 10.8, and 12.1.2 of >>>>>>>> [OSPFV2]. >>>>>>>> >>>>>>>> ! x-Bit >>>>>>>> ! This bit was previously used by MOSPF (see [MOSPF]) >>>>>>>> which has >>>>>>>> been >>>>>>>> ! deprecated for OSPFv3. It should be set to 0 and >>>>>>>> ignored >>>>>>>> upon >>>>>>>> ! reception. It may be reused in the future. >>>>>>>> >>>>>>>> N-bit >>>>>>>> This bit indicates whether or not the router is >>>>>>>> attached to an >>>>>>>> *************** >>>>>>>> *** 4021,4038 **** >>>>>>>> cases or are to be marked as not readvertisable in >>>>>>>> others. >>>>>>>> >>>>>>>> 0 1 2 3 4 5 6 7 >>>>>>>> ! +--+--+--+--+--+--+--+--+ >>>>>>>> ! | | | |DN| P|MC|LA|NU| >>>>>>>> ! +--+--+--+--+--+--+--+--+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 72] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> The Prefix Options field >>>>>>>> --- 4021,4038 ---- >>>>>>>> cases or are to be marked as not readvertisable in >>>>>>>> others. >>>>>>>> >>>>>>>> 0 1 2 3 4 5 6 7 >>>>>>>> ! +--+--+--+--+--+-+--+--+ >>>>>>>> ! | | | |DN| P|x|LA|NU| >>>>>>>> ! +--+--+--+--+--+-+--+--+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 72] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> The Prefix Options field >>>>>>>> *************** >>>>>>>> *** 4050,4059 **** >>>>>>>> Section 3.4.3.9. An implementation MAY also set the >>>>>>>> LA-bit for >>>>>>>> prefixes advertised with a host PrefixLength (128). >>>>>>>> >>>>>>>> ! MC-bit >>>>>>>> ! The "multicast" capability bit. If set, the prefix >>>>>>>> should be >>>>>>>> ! included in IPv6 multicast routing calculations. If >>>>>>>> not set, it >>>>>>>> ! should be excluded. >>>>>>>> >>>>>>>> P-bit >>>>>>>> The "propagate" bit. Set on NSSA area prefixes that >>>>>>>> should be >>>>>>>> --- 4050,4060 ---- >>>>>>>> Section 3.4.3.9. An implementation MAY also set the >>>>>>>> LA-bit for >>>>>>>> prefixes advertised with a host PrefixLength (128). >>>>>>>> >>>>>>>> ! x-bit >>>>>>>> ! This bit was previously defined as a "multicast" >>>>>>>> capability bit. >>>>>>>> ! However, the use was never adequately specified and >>>>>>>> it is being >>>>>>>> ! deprecated. It is set to 0 and ignored upon >>>>>>>> reception. It >>>>>>>> may be >>>>>>>> ! reused in the future. >>>>>>>> >>>>>>>> P-bit >>>>>>>> The "propagate" bit. Set on NSSA area prefixes that >>>>>>>> should be >>>>>>>> *************** >>>>>>>> *** 4193,4209 **** >>>>>>>> >>>>>>>> The LSA function codes are defined as follows. The >>>>>>>> origination >>>>>>>> and >>>>>>>> processing of these LSA function codes are defined >>>>>>>> elsewhere in >>>>>>>> this >>>>>>>> ! document, except for the group-membership-LSA (see >>>>>>>> [MOSPF]) and the >>>>>>>> ! NSSA-LSA (see [NSSA]). As shown below, each LSA >>>>>>>> function code also >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires November 12, 2007 >>>>>>>> [Page 75] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> May >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> ! implies a specific setting for the U, S1, and S2 bits. >>>>>>>> >>>>>>>> >>>>>>>> LSA function code LS Type Description >>>>>>>> --- 4193,4210 ---- >>>>>>>> >>>>>>>> The LSA function codes are defined as follows. The >>>>>>>> origination >>>>>>>> and >>>>>>>> processing of these LSA function codes are defined >>>>>>>> elsewhere in >>>>>>>> this >>>>>>>> ! document, except for the NSSA-LSA (see [NSSA]) and >>>>>>>> 0x2006 which was >>>>>>>> ! previously used by MOSPF (see [MOSPF]). MOSPF has been >>>>>>>> deprecated >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ! Coltun, et al. Expires February 2, 2008 >>>>>>>> [Page 75] >>>>>>>> >>>>>>>> >>>>>>>> ! Internet-Draft OSPF for IPv6 >>>>>>>> August >>>>>>>> 2007 >>>>>>>> >>>>>>>> >>>>>>>> ! f > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Mar 9 03:57:47 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 B21FA3A6BC9; Sun, 9 Mar 2008 03:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.834 X-Spam-Level: X-Spam-Status: No, score=-99.834 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MISSING_HEADERS=1.292, RDNS_NONE=0.1, 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 LApJxWyZhVu9; Sun, 9 Mar 2008 03:57:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4163A6BE0; Sun, 9 Mar 2008 03:57:46 -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 BCC8B3A6BC9 for ; Sun, 9 Mar 2008 03:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 pdwUrgZzB8bW for ; Sun, 9 Mar 2008 03:57:44 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id E1D113A6BAA for ; Sun, 9 Mar 2008 03:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 04E4C9235A3 for ; Sun, 9 Mar 2008 03:55:24 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15171-10 for ; Sun, 9 Mar 2008 03:55:23 -0700 (PDT) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id AFA749235A2 for ; Sun, 9 Mar 2008 03:55:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: Message-Id: <6727DC3B-392D-4BBB-8ECA-88B32917B85A@redback.com> Cc: OSPF List From: Acee Lindem Date: Sun, 9 Mar 2008 06:55:22 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org The OSPF WG Last Call on the subject document has ended. The 05 version will incorporated last call documents and we'll have another brief WG last call after IETF 71. Thanks, Acee On Feb 15, 2008, at 12:15 PM, Acee Lindem wrote: > This starts the WG last call for the subject document. The target > status is Proposed Standard. > The WG last call will begin today and will end March 1st, 2008 at > 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > this protocol extension was published as an experimental RFC 4813. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > http://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 Mar 11 08:34:24 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 E51823A6E38; Tue, 11 Mar 2008 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.335 X-Spam-Level: X-Spam-Status: No, score=-99.335 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1, 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 FY-u-z9d-LlX; Tue, 11 Mar 2008 08:34:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BAFE28C3B2; Tue, 11 Mar 2008 08:34:14 -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 1E94228C30B; Tue, 11 Mar 2008 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 BEn3q8a5FfFr; Tue, 11 Mar 2008 08:34:09 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 117A93A6E0F; Tue, 11 Mar 2008 08:34:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fz/HM9h95Td8pgvQzT729yVCW6E40N8JJ4JNSB0EAVWrw23sR6/W2ElRPZclq1RH; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.113.33] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JZ6S7-0007Vf-Mv; Tue, 11 Mar 2008 11:31:44 -0400 Message-ID: <016a01c8838d$01a2c110$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Joan Cucchiara" , "Romascanu, Dan \(Dan\)" , "Acee Lindem" , , "MIB Doctors \(E-mail\)" References: <039601c88079$dd9d97b0$6601a8c0@JoanPC> Date: Tue, 11 Mar 2008 10:31:41 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654f8482ae1507ae7ce7a991f0c67a8009fa26b888b88ba812a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.113.33 Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Folks, I have a couple of clarifications inline below. Thanks, Joan ----- Original Message ----- From: "Joan Cucchiara" To: "Joan Cucchiara" ; "Romascanu, Dan (Dan)" ; "Acee Lindem" ; ; "MIB Doctors (E-mail)" Cc: "Ronald Bonica" ; "Abhay Roy" ; "Ross Callon" ; "Vishwas Manral" ; "Dan Joyal" ; "Bert Wijnen" ; "David Ward" Sent: Friday, March 07, 2008 12:37 PM Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > Hello, > > I do also have one other question. There seems to be > quite a bit of overlap between RFC4750 (OSPFv2 MIB) > and this draft. While I understand that there are obvious > differences between IPv4 and IPv6 addresses, and also > some differences in OSPFv2 vs. OSPFv3, I still see many > of the same MIB objects in the 2 MIB Modules, did the > authors consider using OSPFv2 MIB and doing AUGMENTS > for OSPFv3? > > Please give me some background/history on why a completely > separate MIB Module was done for OSPFv3. > > Thank you, > Joan > > > ----- Original Message ----- > From: "Joan Cucchiara" > To: "Romascanu, Dan (Dan)" ; "Acee Lindem" > ; ; "MIB Doctors (E-mail)" > > Cc: "Ronald Bonica" ; "Abhay Roy" ; > "Ross Callon" ; "Vishwas Manral" > ; "Dan Joyal" ; "Bert Wijnen" > ; "David Ward" > Sent: Friday, March 07, 2008 2:37 AM > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > >> >> Hi Folks, >> >> First is the output from the MIB tools. >> Followed by some General Comments, and then followed by >> fairly specific comments/questions on the MIB. >> >> Thanks, >> Joan >> >> >> SMICNG results: >> ---------------- >> >> E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" >> in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax specified >> >> E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" >> must be defined with syntax that includes a range >> >> E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" >> must be defined with syntax that includes a range >> >> >> smilint >> ------------ >> severity level requested 6 >> >> line severity problem >> -------------------------- >> >> 2844 5 warning: `InetAddress' object should have an >> accompanied preceding `InetAdressType' object >> (Please see comments below wrt Notifications) >> >> >> >> ID NITS (== 1 warning) >> -------- >> >> == The copyright year in the IETF Trust Copyright Line does not match the >> current year >> >> >> >> >> General Comments >> ----------------- >> >> 1) Need to have a read-only conformance. >> It has been explained to me that the read-only conformance is not a requirement. However, the working group need to be aware of what it means to NOT have a read-only conformance. Here is the relevant text from RFC 4181: - If there are any objects with a MAX-ACCESS value of read-write or read-create for which there is no OBJECT clause that specifies a MIN-ACCESS of read-only, then implementations must support write access to those objects in order to be compliant with that MODULE- COMPLIANCE statement. This fact sometimes catches MIB module authors by surprise. When confronted with such cases, reviewers SHOULD verify that this is indeed what the authors intended, since it often is not. - On the other side of the coin, MIB module authors need to be aware that while a read-only compliance statement is sufficient to support interoperable monitoring applications, it is not sufficient to support interoperable configuration applications. A technique commonly used in MIB modules that are intended to support both monitoring and configuration is to provide both a read-only compliance statement and a full compliance statement. A good example is provided by the DIFFSERV-MIB [RFC3289]. Authors SHOULD consider using this technique when it is applicable. I would ask that the authors and working group comment on the read-only conformance, either for or against, and why. In my personal experience not all operators want to use SNMP to configure, so having a read-only conformance allows MIB implementations to be compliant to the MIB standard. In other words, read-only conformance guides MIB implementors on the interoperability with read-only conformance, just as the full (read and write) conformance does. Certainly, I would encourage this to be added to the MIB, but it is not mandatory. >> 2) I would like to understand the use of the single >> DiscontinuityTime object for all the counters in the >> MIB. My thoughts are that having a few more discontinuity >> objects (specifically in tables) would be more beneficial, >> so please give me some feedback on this, so I can understand >> why only one Discontinuity object is used. >> Having discussed this with other MIB Drs. has lead me to rephrase the above, please comment on 2 issues: a) situations where counters could suffer a discontinuity (e.g. a single OSPFv3 area's counters could have a discontinuity) The reason is that the document specifies only one OSPFv3 related reason for counters to suffer a discontinuity (i.e., the restart of the OSPFv3 routing process) and this is in the text of the document, not the MIB portion of the document. Describing more specific OSPFv3 situations in the MIB document itself would help implementors. b) some of the indexes use InterfaceIndex from the IF-MIB. The counters in these tables "might" be related to the ifCounterDiscontinuityTime object. More discussion on these tables would be helpful to determine if this is so. In essence, more Discontinuity objects may NOT be beneficial, and so would like to discuss a) and b) above before making that determination. Thanks, -Joan >> 3) Throttling of notifications and Polling Event Counters. >> I think more details of this need to be in the MIB itself. >> Please expand some of these DESCRIPTIONS. >> >> 4) Please note that many of my comments apply to the entire MIB, although >> I only commented on the first few objects. Please be sure to check the >> entire MIB for an issue. For example, please rename any RowStatus object >> with xxxRowStatus, please spell out Interval, etc. >> >> 5) The MIB did not extract using mstrip (MIB tool). >> If possible, could this be fixed? >> >> >> Comments in Order of the document >> ---------------------------------- >> >> 1) (NIT) Header should say: >> Proposed Status: Standards Track >> >> >> 2) (NIT) Expiration date has incorrect year. >> >> >> *) (NIT) please be consistent with using >> RFCXXX vs. MIB tree assignment, so for example >> >> DESCRIPTION >> "The MIB module for OSPF version 3. >> >> Copyright (C) The IETF Trust (2007). >> This version of this MIB module is part of >> RFC XXXX; see the RFC itself for full legal >> notices." >> >> REVISION "200709171200Z" >> DESCRIPTION -- RFC Editor assigns RFC XXXX >> "Initial version, published as RFC XXXX" >> >> ::= { mib-2 YYY } -- to be assigned by IANA >> >> >> >> >> *)Ospfv3UpToRefreshIntervalTc >> >> *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3DeadIntRangeTc >> *) Please spell out Interval and change Tc to TC, >> i.e. Ospfv3DeadIntervalRangeTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> *) Ospfv3RouterIdTC >> >> *) Please use TC, Ospfv3RouterIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Please add a reference >> >> *) Ospfv3AreaIdTc >> >> *) Please use TC, Ospfv3AreaIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> >> *) Please add a reference >> >> >> *) Ospfv3IfInstIdTc >> >> *) Please Tc to TC, i.e. Ospfv3IfInstIdTC >> >> *) Could DISPLAY-HINT "d" be used instead? >> >> *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) >> >> *) Please add a reference >> >> >> *) ospfv3RouterId >> >> Isn't this a 32-bit unsigned integer? >> Please add REFERENCE clause. >> >> >> *) ospfv3AreaBdrRtrStatus >> >> Please indicate the value of the flag >> when the router is an area border router. >> (i.e. when the value of this object is true(1)...) >> >> *) ospfv3AsScopeLsaCksumSum >> >> *) should be Unsigned32 >> >> >> *) ospfv3DemandExtensions >> >> Same comment as with the previous object that has SYNTAX of TruthValue, >> please specify, when this object has the value of true(1), then >> the router supports demand circuits... >> >> *) ospfv3ReferenceBandwidth >> >> -Please add UNITS >> -Please add DEFVAL >> - Please add REFERENCE >> >> >> *) ospfv3RestartSupport >> >> -Is there a value which could be considered a DEFVAL for >> this object? >> (In general, please review all the read-write objects >> and add DEFVALs if appropriate). >> >> *) ospfv3RestartInterval >> -Is there a value which could be considered a DEFVAL for >> this object? >> >> >> *) ospfv3RestartStrictLsaChecking >> >> Please indicate what true(1) means in the DESCRIPTION >> (Please do this for all objects which contain a >> TruthValue) >> >> *) ospfv3RestartExitRc >> >> What does the Rc stand for, could this be spelled out? >> >> Are any additional objects needed to tell when the >> value of this object changed? >> >> *) ospfv3NotificationEnable >> >> Why is this object needed? Or,in other words, why >> can't RFC3413 be used. >> >> *) ospfv3StubRouterAdvertisement >> >> Need to add DEFVAL >> Please add a REFERENCE >> >> *) ospfv3AreaTable >> >> - This table has a combination of both objects to configure >> areas and statistics for areas. Could this be devided into >> 2 tables one for configuring and one for status/statics? >> >> Additionally, if is not clear to me what happens when an attached >> area is established and then the configuration changes? Can >> the configurable objects be changed? >> >> Also, the counters in this table refer to ospfv3DiscontinuityTime >> but if the OSPFv3 routing process starts-up, then my understanding >> is that these counters might be affected (specifically, >> ospfv3AreaNssTranslatorEvents), >> so I think another discontinuityTime object is needed...please comment. >> >> >> *) ospfv3AreaId >> >> Isn't this unsigned? >> >> >> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this >> table may have a DEFVAL clause of zero (this is mentioned in >> the DESCRIPTION clauses). >> >> *) ospfv3AreaScopeLsaCksumSum >> >> Should this be Unsigned32? >> >> >> *) ospfv3AreaStatus >> >> Please rename to ospfv3AreaRowStatus >> >> *) ospfv3AreaStubMetric >> >> Is there a DEFVAL for this object? >> >> >> *) ospfv3AreaNssaTranslatorStabInt >> >> Please use entire word Interval >> >> >> >> *) ospfv3AsLsdbSequence >> >> Should this have a range? >> >> *) ospfv3AreaLsdbSequence >> >> (same question, is there a range for this?) >> >> *) ospfv3AreaLsdbAge >> >> Unsigned32 and a range? >> >> What is the value if the DoNotAge Bit is set? >> >> *) ospfv3AreaLsdbChecksum >> >> Should this be unsigned32? >> >> >> *) ospfv3AreaLsdbTypeKnown >> >> Please indicate what true(1) means in the >> DESCRIPTION >> >> *) ospfv3LinkLsdbSequence >> >> Same comment as with the other Sequence numbers, >> should this have a range? Additionally, should these >> sequence numbers have a common TC? >> >> *)ospfv3LinkLsdbAge >> >> same comments and questions >> as with the "Age" object in the prior table? >> >> *) ospfv3LinkLsdbChecksum >> >> Unsigned32? >> >> >> *) ospfv3HostTable >> >> Need to have a storageType object added to this table. >> >> >> >> >> >> *) ospfv3HostStatus >> >> Please rename to ospfv3HostRowStatus >> Usually, this is the last in the list of objects. >> >> *)ospfv3IfTable >> >> Don't understand the REFERENCE here, please explain. >> >> >> Same comment as with the other table, there is mix of >> configuration and status/statistics in this one table. >> Could this be made into 2 tables? >> >> Also, the Counters in this table >> likely need their own discontinuityTime object.... >> >> Can configurable objects change once the interface >> is established (for example, if the interface is pointToPoint?) >> >> >> >> >> *) ospfv3IfTransitDelay >> >> Don't understand the DESCRIPTION here. Could you >> please expand. >> >> Is there a REFERENCE that could be added? >> >> *) ospfv3IfStatus >> >> Please rename to ospfv3IfRowStatus >> >> *) ospfv3IfAdminStat >> >> Would an OperStatus object be beneficial in this >> table? >> >> *) ospfv3IfDemandNbrProbeRetxLimit >> >> Retx is used for Retransmission, elsewhere Retrans >> was used. Please be consistant. >> >> *) ospfv3VirtIfTable >> >> Don't understand the reference here. If this is >> an IPv6/V3 specific table then why are you >> Refering to OSPFv2? Is this correct? Additionally, >> could a OSPFv3 REFERENCE be added also? >> >> Same comments as with the other tables that have >> a mix of config and status/statistics objects. >> >> Please change RowStatus objects to have RowStatus >> at the end of their name. >> >> *) ospfv3NbrTable >> >> Same question as to how the Counters in this table >> can successfully use ospfv3DiscontinuityTime. In other >> words, if this table is specific to neighbors, then >> the counters are also, so there might be (at least it >> seems to me) a case where an entry in this table is >> affected and neighbor counters suffer a discontinuity >> but the ospfv3DiscontinuityTime may not. Please comment. >> >> >> *) ospfv3NbrTable and ospfv3CfgNbrTable >> >> What is the relationship between these 2 tables? >> The indexing is different between the 2 tables and so >> I'm wondering what the relationship is between them. >> >> >> >> *) ospfv3AreaAggregateRouteTag >> >> Is this Unsigned32? >> >> >> Notifications >> ------------ >> >> In general the accessible-for-notify objects should probably be >> changed into read-only objects. Additionally, a timestamp should >> be associated with some of these. There is an assumption made that >> it is better to send out notifications rather than poll, but I'd >> rather give the operator the choice on that. >> >> >> >> >> >> >> >> Compliance Statements >> ------------------------- >> >> * Need a Read-only compliance statement. >> It is missing. >> >> --- >> >> >> >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Mar 11 11:30:17 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 5690228C3BC; Tue, 11 Mar 2008 11:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.977 X-Spam-Level: X-Spam-Status: No, score=-100.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 6ErwMbLudJGu; Tue, 11 Mar 2008 11:30:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CA23A681A; Tue, 11 Mar 2008 11:30:16 -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 338DF3A6A1E for ; Tue, 11 Mar 2008 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 foYALrLTX9h5 for ; Tue, 11 Mar 2008 11:30:14 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 231A13A6810 for ; Tue, 11 Mar 2008 11:30:13 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id z23so2377274fkz.5 for ; Tue, 11 Mar 2008 11:27:54 -0700 (PDT) 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:mime-version:content-type; bh=EmsPUccBe5IiKDYKt9nt5Q4F1RGM6yrCqR9vTHJTmB0=; b=ElYNH8gr5Np95Fe45Ze9LgbCpMNh16nDtxZEWrlKJAXMPRlhdTwXxqIdHOevbDLzT30cMx3JvZjMqShmR/quqVSA8pv4fIe9YofPuYr8WdMVZN+FSIkaekP5ZK6MGayNyyUePZRZc7fH+aZ6heV5JIabSNm25Fwtj8ESsMRx7Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ahr9mBzn0GxYeNfBK9TwxPPnVtgR3M/Bsw4ecm8wlD/4KvQp6Vl0nRL62TVniJ61T2dCZPQs8CHaCEzqvL8uYS3Arq+pLWf7l59GZBPGskke8wgVXxirjBr00DwCQUKEoxKj6TsXEhkCyTVYRVsXwxounZ2hIu8G00xyPGs9urQ= Received: by 10.82.187.2 with SMTP id k2mr17083247buf.26.1205260070271; Tue, 11 Mar 2008 11:27:50 -0700 (PDT) Received: by 10.86.29.1 with HTTP; Tue, 11 Mar 2008 11:27:50 -0700 (PDT) Message-ID: <6b63093f0803111127t78c1b122nb847a4bc7851e5da@mail.gmail.com> Date: Tue, 11 Mar 2008 23:57:50 +0530 From: "Lokesh Jain" To: ospf@ietf.org MIME-Version: 1.0 Subject: [OSPF] Few Queries related to RFC 4577 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="===============0365034233==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0365034233== Content-Type: multipart/alternative; boundary="----=_Part_17211_3600241.1205260070263" ------=_Part_17211_3600241.1205260070263 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I am new to this routing protocol and VPN stuff. Although I have understood BGP/MPLS IP VPN to a large extent. But I am not able to related few concepts in RFC 4577 to BGP/MPLS IP VPN. 1. OSPF domain is said to be a "set of sites in which routes should be distributed as intra-network routes". These sites are under a single VPN or they can be under multiple VPNs. 2. Can one VRF be associated be multiple OSPF instances on a single PE router? If yes, please give an example deployment scenario. 3. OSPF domain identifier is same as Route Distinguisher ? Any pointers towards some tutorials related to RFC 4577 would be of great help :) -- ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take ------=_Part_17211_3600241.1205260070263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

I am new to this routing protocol and VPN stuff. Although I have understood BGP/MPLS IP VPN to a large extent. But I am not able to related few concepts in RFC 4577 to BGP/MPLS IP VPN.

1. OSPF domain is said to be a "set of sites in which routes should be distributed as intra-network routes". These sites are under a single VPN or they can be under multiple VPNs.
2. Can one VRF be associated be multiple OSPF instances on a single PE router? If yes, please give an example deployment scenario.
3. OSPF domain identifier is same as Route Distinguisher ?

Any pointers towards some tutorials related to RFC 4577 would be of great help :)

--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take ------=_Part_17211_3600241.1205260070263-- --===============0365034233== 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 --===============0365034233==-- From ospf-bounces@ietf.org Thu Mar 13 02:15:06 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 6916E28C639; Thu, 13 Mar 2008 02:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.196 X-Spam-Level: X-Spam-Status: No, score=-100.196 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1, 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 cuFJbHoS5MDU; Thu, 13 Mar 2008 02:15:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCB83A6D8A; Thu, 13 Mar 2008 02:15:05 -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 449EC3A6D8A for ; Thu, 13 Mar 2008 02:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Ciq1ZPkpt4tu for ; Thu, 13 Mar 2008 02:15:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id A9A0A3A6871 for ; Thu, 13 Mar 2008 02:15:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2696472fgg.41 for ; Thu, 13 Mar 2008 02:12:42 -0700 (PDT) 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:mime-version:content-type; bh=NtYqRkFCtUvFkoyETTNBgS9F1Mznm9rKqko7uDYl7Qo=; b=mLXUwuBWCuU4UhxVh74awp4+c9/ZXtzo7sjSwMgQq5uK6mvlJmrz46gP00gvYBM8g9diPWNyxk7krMVQ0aKPeYqXqGTR2ATtvg4DyuPFxnEyP1BzFJhvyvelo+UN6gNr6vOYT7n9yIRgdETFGVbmepIj2dz9OUbjukJL7FICphg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ph5sQgM6hcVH/SN50bjaWLZdSrsuo4am0WWZKHFbiGrxoc83qekQaRIyocn/SrGvE8Qe3F6f9EPcd31Wr9qBMshl3+tBz4QZx10wbhvM0MDCE7hZp8eoGYeer+SamLv9OHJia5xuwnAZidUceiosrkM7byPZUyrzxDYrOiJWWH4= Received: by 10.82.186.5 with SMTP id j5mr22515920buf.38.1205399561645; Thu, 13 Mar 2008 02:12:41 -0700 (PDT) Received: by 10.86.29.1 with HTTP; Thu, 13 Mar 2008 02:12:41 -0700 (PDT) Message-ID: <6b63093f0803130212u3d480ca2v5495a67c57a56633@mail.gmail.com> Date: Thu, 13 Mar 2008 14:42:41 +0530 From: "Lokesh Jain" To: ospf@ietf.org MIME-Version: 1.0 Subject: [OSPF] Sham link query 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="===============0339537737==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0339537737== Content-Type: multipart/alternative; boundary="----=_Part_738_11110996.1205399561625" ------=_Part_738_11110996.1205399561625 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have a doubt regarding packet (data packets, lsa, hello packets) forwarding on Sham Link. On two different PEs, we establish a Sham link between two VRFs. The Sham Link End point Address on each PE is associated with one OSPF instance and advertised by the BGP into the backbone. Is this advertisement done in the same way as for any other route (advertising a VPN label for the route) ? So on both PEs, the routing entry (BGP) will be stored in corresponding VRF(along with VPN label) along with next hop information (which will be taken from default VRF). On this sham link, hello/dd/LSA packets (basically OSPF originated packets) as well as data packets (host originated) will be forwarded. What is the difference in the labels applied by the ingress PE router for both type of packets, if any? -- ~~~~~~~~~~~~~ Thanks & Regards, ~~~~~~~~~~~~~ Lokesh Jain Senior Software Engineer, Samsung India Software Operations Pvt. Ltd., Bagmane Tech Park, C V Raman Nagar, Bangalore. Mob: 9880611348 ----------------------------------------------------- You always miss 100% of the chances u don't take ------=_Part_738_11110996.1205399561625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

I have a doubt regarding packet (data packets, lsa, hello packets) forwarding on Sham Link.

On two different PEs, we establish a Sham link between two VRFs. The Sham Link End point Address on each PE is associated with one OSPF instance and advertised by the BGP into the backbone. Is this advertisement done in the same way as for any other route (advertising a VPN label for the route) ?

So on both PEs, the routing entry (BGP) will be stored in corresponding VRF(along with VPN label) along with next hop information (which will be taken from default VRF).

On this sham link, hello/dd/LSA packets (basically OSPF originated packets) as well as data packets (host originated) will be forwarded. What is the difference in the labels applied by the ingress PE router for both type of packets, if any?

--
~~~~~~~~~~~~~
Thanks & Regards,
~~~~~~~~~~~~~
Lokesh Jain
Senior Software Engineer,
Samsung India Software Operations Pvt. Ltd.,
Bagmane Tech Park, C V Raman Nagar,
Bangalore.
Mob: 9880611348
-----------------------------------------------------
You always miss 100% of the chances u don't take ------=_Part_738_11110996.1205399561625-- --===============0339537737== 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 --===============0339537737==-- From ospf-bounces@ietf.org Thu Mar 13 07:15:38 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 A3A7728C873; Thu, 13 Mar 2008 07:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 JYrFsugTGMcj; Thu, 13 Mar 2008 07:15:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFB728C108; Thu, 13 Mar 2008 07:15:27 -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 878D13A69D5 for ; Thu, 13 Mar 2008 07:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 X-6zNw9SpT+b for ; Thu, 13 Mar 2008 07:15:20 -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 94F4E28C108 for ; Thu, 13 Mar 2008 07:14:16 -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 m2DEBwc04157; Thu, 13 Mar 2008 15:11:58 +0100 (CET) Received: from [144.254.245.169] (dhcp-bts02-144-254-245-169.cisco.com [144.254.245.169]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2DEBvL14923; Thu, 13 Mar 2008 15:11:57 +0100 (CET) Message-ID: <47D9362D.2090503@cisco.com> Date: Thu, 13 Mar 2008 15:11:57 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en, zh, ja, ko, de, ar, ru, fr, es, it, pt MIME-Version: 1.0 To: Lokesh Jain References: <6b63093f0803111127t78c1b122nb847a4bc7851e5da@mail.gmail.com> In-Reply-To: <6b63093f0803111127t78c1b122nb847a4bc7851e5da@mail.gmail.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Few Queries related to RFC 4577 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 Lokesh Lokesh Jain wrote: > Hi All, > > I am new to this routing protocol and VPN stuff. Although I have > understood BGP/MPLS IP VPN to a large extent. But I am not able to > related few concepts in RFC 4577 to BGP/MPLS IP VPN. > > 1. OSPF domain is said to be a "set of sites in which routes should be > distributed as intra-network routes". These sites are under a single VPN > or they can be under multiple VPNs. typically part of a single VPN, but they can be part of multiple as well. > 2. Can one VRF be associated be multiple OSPF instances on a single PE > router? If yes, please give an example deployment scenario. nothing prevent you to do that. People use multiple OSPF processes in the same VRF for various things, even though it's not always the best design choice. > 3. OSPF domain identifier is same as Route Distinguisher ? no, OSPF domain-id is a OSPF specific variable. thanks, Peter > > Any pointers towards some tutorials related to RFC 4577 would be of > great help :) > > -- > ~~~~~~~~~~~~~ > Thanks & Regards, > ~~~~~~~~~~~~~ > Lokesh Jain > Senior Software Engineer, > Samsung India Software Operations Pvt. Ltd., > Bagmane Tech Park, C V Raman Nagar, > Bangalore. > Mob: 9880611348 > ----------------------------------------------------- > You always miss 100% of the chances u don't take > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 13 07:20:09 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 EF54C28C176; Thu, 13 Mar 2008 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1, 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 fIYFeMTKiNVr; Thu, 13 Mar 2008 07:20:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714723A6E5D; Thu, 13 Mar 2008 07:20:07 -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 3584E28C123 for ; Thu, 13 Mar 2008 07:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 pfKuRj1igI4n for ; Thu, 13 Mar 2008 07:20:00 -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 225023A6E5A for ; Thu, 13 Mar 2008 07:19:59 -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 m2DEHfA04747; Thu, 13 Mar 2008 15:17:41 +0100 (CET) Received: from [144.254.245.169] (dhcp-bts02-144-254-245-169.cisco.com [144.254.245.169]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m2DEHfL00284; Thu, 13 Mar 2008 15:17:41 +0100 (CET) Message-ID: <47D93784.8030708@cisco.com> Date: Thu, 13 Mar 2008 15:17:40 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en, zh, ja, ko, de, ar, ru, fr, es, it, pt MIME-Version: 1.0 To: Lokesh Jain References: <6b63093f0803130212u3d480ca2v5495a67c57a56633@mail.gmail.com> In-Reply-To: <6b63093f0803130212u3d480ca2v5495a67c57a56633@mail.gmail.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Sham link query 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 Lokesh, Lokesh Jain wrote: > Hi All, > > I have a doubt regarding packet (data packets, lsa, hello packets) > forwarding on Sham Link. > > On two different PEs, we establish a Sham link between two VRFs. The > Sham Link End point Address on each PE is associated with one OSPF > instance and advertised by the BGP into the backbone. Is this > advertisement done in the same way as for any other route (advertising a > VPN label for the route) ? SL endpoint addresses are addresses that reside in the VRF space and are advertised as BGP VPNv4 routes. SL endpoint addresses should not be advertised by OSPF itself. > > So on both PEs, the routing entry (BGP) will be stored in corresponding > VRF(along with VPN label) along with next hop information (which will be > taken from default VRF). right. > > On this sham link, hello/dd/LSA packets (basically OSPF originated > packets) as well as data packets (host originated) will be forwarded. > What is the difference in the labels applied by the ingress PE router > for both type of packets, if any? no difference if the 'host originated' above means originated by the PE and sent to the SL destination address on remote PE. Peter > > -- > ~~~~~~~~~~~~~ > Thanks & Regards, > ~~~~~~~~~~~~~ > Lokesh Jain > Senior Software Engineer, > Samsung India Software Operations Pvt. Ltd., > Bagmane Tech Park, C V Raman Nagar, > Bangalore. > Mob: 9880611348 > ----------------------------------------------------- > You always miss 100% of the chances u don't take > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 13 10:06:15 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 4E58328C4D6; Thu, 13 Mar 2008 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077, 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 5KT1as2zzgrI; Thu, 13 Mar 2008 10:06:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4223928C2BF; Thu, 13 Mar 2008 10:06:11 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF67128C284 for ; Thu, 13 Mar 2008 10:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 dSbp632-kaci for ; Thu, 13 Mar 2008 10:06:05 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id A181328C1CA for ; Thu, 13 Mar 2008 10:06:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4261E616EEE for ; Thu, 13 Mar 2008 10:03:48 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25708-08 for ; Thu, 13 Mar 2008 10:03:48 -0700 (PDT) Received: from [????????p???e8?$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id F374B616EED for ; Thu, 13 Mar 2008 10:03:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: OSPF List From: Acee Lindem Date: Thu, 13 Mar 2008 13:03:47 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] KMART BOF 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'm been getting a lot of E-mails (well, at least 2) on the KMART BOF. There is no separate mailing list and we will not form a WG group. Here is the BOF summary I wrote: The KMART (Key MAnagement for RouTing protocols) BOF took place on Wednesday, March 12. The name is somewhat of a misnomer as the meeting evolved into a sharing of perspectives between the Routing Area and Security Area on the direction for securing the routing protocols. No less than Four ADs spoke including Tim Polk on why he formed the BOF, Ross Callon on requirements for routing security (mainly authentication), Dave Ward on his perspective of the problems with the current IGPs, and Ron Bonica on the operational characteristics of BGP. Additionally, Sandra Murphy presented a brief summary of attacks on routing protocols and Eric Rescorla gave a fast paced tutorial on key management. The BOF was very well attended and the discussion was productive. We were particularly pleased that some the of ISP folks came to the mike and told us what problems they felt were the most pressing to solve. We'd like to encourage this dialogue to continue. The only action items from the meeting were for the Security Area to revisit the wording in RFC 3365 with respect to the routing protocol environment and for the Routing Area to pursue completion of some of the authentication work in the pipeline with renewed vigor. The TCP Authentication Option (which is actually in the Transport Area) was cited several times. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 13 10:19:41 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 7C5963A67AD; Thu, 13 Mar 2008 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.581 X-Spam-Level: X-Spam-Status: No, score=-100.581 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 KfLxeWYh27nb; Thu, 13 Mar 2008 10:19:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0F93A6870; Thu, 13 Mar 2008 10:19:39 -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 661623A6870 for ; Thu, 13 Mar 2008 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 WrU9atZh0eGD for ; Thu, 13 Mar 2008 10:19:37 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 5ECAB3A67AD for ; Thu, 13 Mar 2008 10:19:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3756896wfa.31 for ; Thu, 13 Mar 2008 10:17:19 -0700 (PDT) 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=RQmb+5JEj9rbnC8jno0fc9GwFawIPH/1cv7IVPBRmKg=; b=Ucxdqs9bMbdJY5XtSLq1ZVqhFy1HkxwYiFCd25A+4GGvj+C/g33Es28zlChOAe5D01iAEcsOzGo1rMOzhlZXeX7jR0xiGNtHFZ64NjteEj1wSVilL1gVOh3ZqZM/dS4GnpzdgRTqmm8IK+HK5Mn16OKfWZGlF04Xr9wBbKNHIgU= 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=LpQEn9SmEwnrdjdsOvdEwR2cx71sBEFT9yLL9zspVs0/qcZIMab62drMLuJdjtVRUncG+Pttw+Q9r6mrouD85slJyOpGeyw7vVutdPRyI0tLsI/Y2pznn3dvQcA4JhX4FvjtY8iptByS9Kea2yR6KqBmp4P4MIahFcWmg9EBA50= Received: by 10.142.125.5 with SMTP id x5mr4452314wfc.40.1205428636754; Thu, 13 Mar 2008 10:17:16 -0700 (PDT) Received: by 10.143.164.14 with HTTP; Thu, 13 Mar 2008 10:17:16 -0700 (PDT) Message-ID: <77ead0ec0803131017i5dbd6682tee22f190ed0705f4@mail.gmail.com> Date: Thu, 13 Mar 2008 10:17:16 -0700 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: OSPF List Subject: Re: [OSPF] KMART BOF 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, Thanks for pushing the effort on this front forward and letting us into the KMART story.:) Thanks a lot also for chairing the effort to help in its progress. In my view attacks on routing systems are relatively very easy and considerably more catastrophic than currently known end user attacks. I have been working on pushing similar issues for the last 3 years and am pleased to see more vigor around the same. I had presented similar work in IETF63 at the OSPF-WG which included a shorter as well as longer term work (automated keying) for the same. http://www.ietf.org/proceedings/05aug/slides/ospf-6/sld1.htm. Thanks again, Vishwas On Thu, Mar 13, 2008 at 10:03 AM, Acee Lindem wrote: > I'm been getting a lot of E-mails (well, at least 2) on the KMART > BOF. There is no separate mailing list and we will not form a WG > group. Here is the BOF summary I wrote: > > > The KMART (Key MAnagement for RouTing protocols) BOF took place on > Wednesday, March 12. The name is somewhat of a misnomer as the > meeting evolved into a sharing of perspectives between the Routing > Area and Security Area on the direction for securing the routing > protocols. No less than Four ADs spoke including Tim Polk on why he > formed the BOF, Ross Callon on requirements for routing security > (mainly authentication), Dave Ward on his perspective of the problems > with the current IGPs, and Ron Bonica on the operational > characteristics of BGP. Additionally, Sandra Murphy presented a brief > summary of attacks on routing protocols and Eric Rescorla gave a fast > paced tutorial on key management. The BOF was very well attended and > the discussion was productive. We were particularly pleased that some > the of ISP folks came to the mike and told us what problems they felt > were the most pressing to solve. We'd like to encourage this dialogue > to continue. The only action items from the meeting were for the > Security Area to revisit the wording in RFC 3365 with respect to the > routing protocol environment and for the Routing Area to pursue > completion of some of the authentication work in the pipeline with > renewed vigor. The TCP Authentication Option (which is actually in > the Transport Area) was cited several times. > > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 13 14:55:01 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 DEAD128C846; Thu, 13 Mar 2008 14:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 GlQQgOxKTPmh; Thu, 13 Mar 2008 14:55:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5888E3A6CF2; Thu, 13 Mar 2008 14:54:50 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E1128C4AF; Thu, 13 Mar 2008 14:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 OQ9sf6yfRqLe; Thu, 13 Mar 2008 14:54:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9D2793A6981; Thu, 13 Mar 2008 14:54:47 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2DLqOq07929; Thu, 13 Mar 2008 21:52:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 17:51:46 -0400 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501413B24A9D@zrtphxm1.corp.nortel.com> In-Reply-To: <016a01c8838d$01a2c110$6601a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt thread-index: AciDjQ8uyUt557HuSRWCT5VnybnAHQBoFF1w References: <016a01c8838d$01a2c110$6601a8c0@JoanPC> From: "Daniel Joyal" To: "Joan Cucchiara" , "Romascanu, Dan (Dan)" , "Acee Lindem" , , "MIB Doctors (E-mail)" Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, Please see my comments below. Thanks. -Dan > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Tuesday, March 11, 2008 11:32 AM > To: Joan Cucchiara; Romascanu, Dan (Dan); Acee Lindem; > ospf@ietf.org; MIB Doctors (E-mail) > Cc: Ronald Bonica; Abhay Roy; Ross Callon; Vishwas Manral; > Joyal, Daniel (BL60:SF23); Bert Wijnen; David Ward > Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > Hi Folks, > > I have a couple of clarifications inline below. > > Thanks, > Joan > > > ----- Original Message ----- > From: "Joan Cucchiara" > To: "Joan Cucchiara" ; "Romascanu, > Dan (Dan)" > ; "Acee Lindem" ; > ; "MIB Doctors (E-mail)" > Cc: "Ronald Bonica" ; "Abhay Roy" > ; "Ross Callon" ; > "Vishwas Manral" > ; "Dan Joyal" ; > "Bert Wijnen" > ; "David Ward" > Sent: Friday, March 07, 2008 12:37 PM > Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > > > > Hello, > > > > I do also have one other question. There seems to be quite > a bit of > > overlap between RFC4750 (OSPFv2 MIB) and this draft. While I > > understand that there are obvious differences between IPv4 and IPv6 > > addresses, and also some differences in OSPFv2 vs. OSPFv3, > I still see > > many of the same MIB objects in the 2 MIB Modules, did the authors > > consider using OSPFv2 MIB and doing AUGMENTS for OSPFv3? > > > > Please give me some background/history on why a completely separate > > MIB Module was done for OSPFv3. > > > > Thank you, > > Joan > > > > > > ----- Original Message ----- > > From: "Joan Cucchiara" > > To: "Romascanu, Dan (Dan)" ; "Acee Lindem" > > ; ; "MIB Doctors (E-mail)" > > > > Cc: "Ronald Bonica" ; "Abhay Roy" > > ; "Ross Callon" ; > "Vishwas Manral" > > ; "Dan Joyal" ; > "Bert Wijnen" > > ; "David Ward" > > Sent: Friday, March 07, 2008 2:37 AM > > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > > [snip] > >> > >> General Comments > >> ----------------- > >> > >> 1) Need to have a read-only conformance. > >> > > It has been explained to me that the read-only conformance > is not a requirement. > However, the working group need to be aware of what it means > to NOT have a read-only conformance. > > Here is the relevant text from RFC 4181: > > - If there are any objects with a MAX-ACCESS value of read-write or > read-create for which there is no OBJECT clause that specifies a > MIN-ACCESS of read-only, then implementations must support write > access to those objects in order to be compliant with > that MODULE- > COMPLIANCE statement. This fact sometimes catches MIB module > authors by surprise. When confronted with such cases, reviewers > SHOULD verify that this is indeed what the authors > intended, since > it often is not. > > - On the other side of the coin, MIB module authors need > to be aware > that while a read-only compliance statement is sufficient to > support interoperable monitoring applications, it is not > sufficient > to support interoperable configuration applications. A technique > commonly used in MIB modules that are intended to support both > monitoring and configuration is to provide both a read-only > compliance statement and a full compliance statement. A good > example is provided by the DIFFSERV-MIB [RFC3289]. > Authors SHOULD > consider using this technique when it is applicable. > > I would ask that the authors and working group comment on the > read-only conformance, either for or against, and why. In my personal > experience not all operators want to use SNMP to configure, so having > a read-only conformance allows MIB implementations to be compliant > to the MIB standard. In other words, read-only conformance guides > MIB implementors on the interoperability with read-only conformance, > just as the full (read and write) conformance does. > Certainly, I would > encourage this to be added to the MIB, but it is not mandatory. > Since it's not mandatory, do many MIB authors opt to add a read-only conformance? In other words, is it common practice? > >> 2) I would like to understand the use of the single > >> DiscontinuityTime object for all the counters in the > >> MIB. My thoughts are that having a few more discontinuity > >> objects (specifically in tables) would be more beneficial, > >> so please give me some feedback on this, so I can understand > >> why only one Discontinuity object is used. > >> > > Having discussed this with other MIB Drs. has lead me to > rephrase the above, please comment on 2 issues: > > a) situations where counters could suffer a discontinuity > (e.g. a single OSPFv3 area's counters could have a discontinuity) > The reason is that the document specifies only one OSPFv3 related > reason for counters to suffer a discontinuity (i.e., the > restart of the > OSPFv3 > routing process) and this is in the text of the document, not the MIB > portion > of the document. Describing more specific OSPFv3 situations > in the MIB > document itself > would help implementors. The thinking was that an OSPFv3 instance would never clear its SNMP counters after it is started, so only the coarse discontinuity timer is necessary. I will add the text into the MIB module in the discontinuity timer object description. > > b) some of the indexes use InterfaceIndex from the IF-MIB. > The counters > in these tables "might" be related to the ifCounterDiscontinuityTime > object. > More discussion on these tables would be helpful to determine if this > is so. The ifCounterDiscontinuityTime does not apply to the counters associated with OSPFv3 interfaces. > > In essence, more Discontinuity objects may NOT be beneficial, and so > would like to discuss a) and b) above before making that > determination. > > Thanks, > -Joan > [snip to end] _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 14 07:00:18 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 B7C983A6F56; Fri, 14 Mar 2008 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.15 X-Spam-Level: X-Spam-Status: No, score=-99.15 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RDNS_NONE=0.1, 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 jSjMy0PQXCu5; Fri, 14 Mar 2008 07:00:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873EB3A6D2C; Fri, 14 Mar 2008 07:00:17 -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 A97F33A6EE6 for ; Fri, 14 Mar 2008 07:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Rhys5CIfg7ra for ; Fri, 14 Mar 2008 07:00:12 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id C63223A6999 for ; Fri, 14 Mar 2008 07:00:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 25DF14BAF39 for ; Fri, 14 Mar 2008 06:57:56 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20076-03 for ; Fri, 14 Mar 2008 06:57:56 -0700 (PDT) Received: from [?d?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id B80CA4BAF38 for ; Fri, 14 Mar 2008 06:57:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: Message-Id: <571CCB29-3181-4AE9-A7CB-1309DCC9819D@redback.com> Cc: OSPF List From: Acee Lindem Date: Fri, 14 Mar 2008 09:57:54 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [OSPF] KMART BOF 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="===============0327634975==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0327634975== Content-Type: multipart/alternative; boundary=Apple-Mail-4--437392456 --Apple-Mail-4--437392456 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed One correction - it RFC 4107 that mandated automated key management: http://www.ietf.org/rfc/rfc4107.txt?number=4107 Thanks, Acee On Mar 13, 2008, at 1:03 PM, Acee Lindem wrote: > I'm been getting a lot of E-mails (well, at least 2) on the KMART > BOF. There is no separate mailing list and we will not form a WG > group. Here is the BOF summary I wrote: > > > The KMART (Key MAnagement for RouTing protocols) BOF took place on > Wednesday, March 12. The name is somewhat of a misnomer as the > meeting evolved into a sharing of perspectives between the Routing > Area and Security Area on the direction for securing the routing > protocols. No less than Four ADs spoke including Tim Polk on why he > formed the BOF, Ross Callon on requirements for routing security > (mainly authentication), Dave Ward on his perspective of the > problems with the current IGPs, and Ron Bonica on the operational > characteristics of BGP. Additionally, Sandra Murphy presented a > brief summary of attacks on routing protocols and Eric Rescorla > gave a fast paced tutorial on key management. The BOF was very well > attended and the discussion was productive. We were particularly > pleased that some the of ISP folks came to the mike and told us > what problems they felt were the most pressing to solve. We'd like > to encourage this dialogue to continue. The only action items from > the meeting were for the Security Area to revisit the wording in > RFC 3365 with respect to the routing protocol environment and for > the Routing Area to pursue completion of some of the authentication > work in the pipeline with renewed vigor. The TCP Authentication > Option (which is actually in the Transport Area) was cited several > times. > > > Thanks, > Acee > --Apple-Mail-4--437392456 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII One correction - it RFC 4107 that mandated automated key = management:
Thanks,
I'm been getting a lot of = E-mails (well, at least 2) on the KMART BOF. There is no separate = mailing list and we will not form a WG group. Here is the BOF summary I = wrote:


The = KMART (Key MAnagement for RouTing protocols) BOF took place on = Wednesday, March 12. The name is somewhat of a misnomer as the meeting = evolved into a sharing of perspectives between the Routing Area and = Security Area on the direction for securing the routing protocols. No = less than Four ADs spoke including Tim Polk on why he formed the BOF, = Ross Callon on requirements for routing security (mainly = authentication), Dave Ward on his perspective of the problems with the = current IGPs, and Ron Bonica on the operational characteristics of BGP. = Additionally, Sandra Murphy presented a brief summary of attacks on = routing protocols and Eric Rescorla gave a fast paced tutorial on key = management. The BOF was very well attended and the discussion was = productive. We were particularly pleased that some the of ISP folks came = to the mike and told us what problems they felt were the most pressing = to solve. We'd like to encourage this dialogue to continue. The only = action items from the meeting were for the Security Area to revisit the = wording in RFC 3365 with respect to the routing protocol environment and = for the Routing Area to pursue completion of some of the authentication = work in the pipeline with renewed vigor. The TCP Authentication Option = (which is actually in the Transport Area) was cited several = times.


Acee

=

= --Apple-Mail-4--437392456-- --===============0327634975== 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 --===============0327634975==-- From retiresx@istante.com Mon Mar 17 08:18:41 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 0B6763A6AA1 for ; Mon, 17 Mar 2008 08:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.884 X-Spam-Level: **** X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVeprXQLfLCX for ; Mon, 17 Mar 2008 08:18:37 -0700 (PDT) Received: from p549f2582.dip0.t-ipconnect.de (p549F2582.dip0.t-ipconnect.de [84.159.37.130]) by core3.amsl.com (Postfix) with ESMTP id 6DD4828C108 for ; Mon, 17 Mar 2008 08:18:36 -0700 (PDT) Message-ID: <01c8884a$3ba9cb80$82259f54@retiresx> From: "Alexis Shaffer" To: Subject: OneNote 2007 Date: Mon, 17 Mar 2008 16:16:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 X-Spam: Not detected Microsoft Office Enterprise 2007 includes: • Access 2007 • Communicator 2007 • Excel 2007 • Groove 2007 • InfoPath 2007 • OneNote 2007 • Outlook 2007 • PowerPoint 2007 • Publisher 2007 • Word 2007 http://sueeatmandn181.blogspot.com System Requirements • Intel® Pentium® or AMD® 500 MHz processor • Microsoft Windows® XP Professional or Home Edition with Service Pack 2, Windows Server® 2003 with SP1 , Microsoft Windows Vista. • 256 Mb of RAM • 2GB of available hard-disk space. • 1024x768 or higher resolution monitor • Some features require Microsoft Windows Desktop Search 3.0, Microsoft Windows Media Player 9.0, Microsoft DirectX 9.0b, Microsoft Active Sync 4.1 From fijiigy6@ptkids.com Mon Mar 17 16:07:33 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 68EDB3A6863 for ; Mon, 17 Mar 2008 16:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.303 X-Spam-Level: **** X-Spam-Status: No, score=4.303 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmFy9iY6P2JS for ; Mon, 17 Mar 2008 16:07:33 -0700 (PDT) Received: from goz78.internetdsl.tpnet.pl (goz78.internetdsl.tpnet.pl [83.3.129.78]) by core3.amsl.com (Postfix) with ESMTP id 907453A6803 for ; Mon, 17 Mar 2008 16:07:32 -0700 (PDT) Message-ID: <01c8888b$be76fd80$4e810353@fijiigy6> From: "Zelma Solomon" To: Subject: Microsoft Office OEM version Date: Tue, 18 Mar 2008 00:05:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam: Not detected Microsoft Office Enterprise 2007 includes: • Access 2007 • Communicator 2007 • Excel 2007 • Groove 2007 • InfoPath 2007 • OneNote 2007 • Outlook 2007 • PowerPoint 2007 • Publisher 2007 • Word 2007 http://leagowinskr309.blogspot.com System Requirements • Intel® Pentium® or AMD® 500 MHz processor • Microsoft Windows® XP Professional or Home Edition with Service Pack 2, Windows Server® 2003 with SP1 , Microsoft Windows Vista. • 256 Mb of RAM • 2GB of available hard-disk space. • 1024x768 or higher resolution monitor • Some features require Microsoft Windows Desktop Search 3.0, Microsoft Windows Media Player 9.0, Microsoft DirectX 9.0b, Microsoft Active Sync 4.1 From ospf-bounces@ietf.org Mon Mar 17 21:08:19 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 2062B3A6DEA; Mon, 17 Mar 2008 21:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 XI9Okfyr2ivL; Mon, 17 Mar 2008 21:08:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA80C3A6943; Mon, 17 Mar 2008 21:08:17 -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 859023A68EC; Mon, 17 Mar 2008 21:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 QRai31PkFeU3; Mon, 17 Mar 2008 21:08:15 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id B2CAE3A6930; Mon, 17 Mar 2008 21:08:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fyQm5O0/iqAHrsnacuyPKZM9oLhhNtApCkBFG103dZAG0ph5hrhadTbCpTm4AeDY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.113.33] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JbT5E-0004qd-Su; Tue, 18 Mar 2008 00:05:53 -0400 Message-ID: <00d801c888ad$5ae647e0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Daniel Joyal" , "Romascanu, Dan \(Dan\)" , "Acee Lindem" , , "MIB Doctors \(E-mail\)" References: <016a01c8838d$01a2c110$6601a8c0@JoanPC> <4B7DAC3FEFD35D4A96BDD0116990501413B24A9D@zrtphxm1.corp.nortel.com> Date: Mon, 17 Mar 2008 23:05:50 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654b7578c342a54f0115154410b7e4e449daf78f7fbf31ba7be350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.113.33 Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org > ----- Original Message ----- > From: "Daniel Joyal" > To: "Joan Cucchiara" ; "Romascanu, Dan (Dan)" > ; "Acee Lindem" ; ; > "MIB Doctors (E-mail)" > Cc: "Ronald Bonica" ; "Abhay Roy" ; > "Ross Callon" ; "Vishwas Manral" > ; "Bert Wijnen" ; "David > Ward" > > Sent: Thursday, March 13, 2008 4:51 PM > Subject: RE: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > Hi, > > Please see my comments below. > > Thanks. > -Dan > >> -----Original Message----- >> From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] >> Sent: Tuesday, March 11, 2008 11:32 AM >> To: Joan Cucchiara; Romascanu, Dan (Dan); Acee Lindem; >> ospf@ietf.org; MIB Doctors (E-mail) >> Cc: Ronald Bonica; Abhay Roy; Ross Callon; Vishwas Manral; >> Joyal, Daniel (BL60:SF23); Bert Wijnen; David Ward >> Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt >> >> Hi Folks, >> >> I have a couple of clarifications inline below. >> >> Thanks, >> Joan >> >> >> ----- Original Message ----- >> From: "Joan Cucchiara" >> To: "Joan Cucchiara" ; "Romascanu, >> Dan (Dan)" >> ; "Acee Lindem" ; >> ; "MIB Doctors (E-mail)" >> Cc: "Ronald Bonica" ; "Abhay Roy" >> ; "Ross Callon" ; >> "Vishwas Manral" >> ; "Dan Joyal" ; >> "Bert Wijnen" >> ; "David Ward" >> Sent: Friday, March 07, 2008 12:37 PM >> Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt >> >> >> > >> > Hello, >> > >> > I do also have one other question. There seems to be quite >> a bit of >> > overlap between RFC4750 (OSPFv2 MIB) and this draft. While I >> > understand that there are obvious differences between IPv4 and IPv6 >> > addresses, and also some differences in OSPFv2 vs. OSPFv3, >> I still see >> > many of the same MIB objects in the 2 MIB Modules, did the authors >> > consider using OSPFv2 MIB and doing AUGMENTS for OSPFv3? >> > >> > Please give me some background/history on why a completely separate >> > MIB Module was done for OSPFv3. >> > >> > Thank you, >> > Joan >> > >> > >> > ----- Original Message ----- >> > From: "Joan Cucchiara" >> > To: "Romascanu, Dan (Dan)" ; "Acee Lindem" >> > ; ; "MIB Doctors (E-mail)" >> > >> > Cc: "Ronald Bonica" ; "Abhay Roy" >> > ; "Ross Callon" ; >> "Vishwas Manral" >> > ; "Dan Joyal" ; >> "Bert Wijnen" >> > ; "David Ward" >> > Sent: Friday, March 07, 2008 2:37 AM >> > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt >> > >> > > [snip] >> >> >> >> General Comments >> >> ----------------- >> >> >> >> 1) Need to have a read-only conformance. >> >> >> >> It has been explained to me that the read-only conformance >> is not a requirement. >> However, the working group need to be aware of what it means >> to NOT have a read-only conformance. >> >> Here is the relevant text from RFC 4181: >> >> - If there are any objects with a MAX-ACCESS value of read-write or >> read-create for which there is no OBJECT clause that specifies a >> MIN-ACCESS of read-only, then implementations must support write >> access to those objects in order to be compliant with >> that MODULE- >> COMPLIANCE statement. This fact sometimes catches MIB module >> authors by surprise. When confronted with such cases, reviewers >> SHOULD verify that this is indeed what the authors >> intended, since >> it often is not. >> >> - On the other side of the coin, MIB module authors need >> to be aware >> that while a read-only compliance statement is sufficient to >> support interoperable monitoring applications, it is not >> sufficient >> to support interoperable configuration applications. A technique >> commonly used in MIB modules that are intended to support both >> monitoring and configuration is to provide both a read-only >> compliance statement and a full compliance statement. A good >> example is provided by the DIFFSERV-MIB [RFC3289]. >> Authors SHOULD >> consider using this technique when it is applicable. >> >> I would ask that the authors and working group comment on the >> read-only conformance, either for or against, and why. In my personal >> experience not all operators want to use SNMP to configure, so having >> a read-only conformance allows MIB implementations to be compliant >> to the MIB standard. In other words, read-only conformance guides >> MIB implementors on the interoperability with read-only conformance, >> just as the full (read and write) conformance does. >> Certainly, I would >> encourage this to be added to the MIB, but it is not mandatory. >> > > Since it's not mandatory, do many MIB authors opt to add a > read-only conformance? In other words, is it common practice? > Yes, it is common practice. > >> >> 2) I would like to understand the use of the single >> >> DiscontinuityTime object for all the counters in the >> >> MIB. My thoughts are that having a few more discontinuity >> >> objects (specifically in tables) would be more beneficial, >> >> so please give me some feedback on this, so I can understand >> >> why only one Discontinuity object is used. >> >> >> >> Having discussed this with other MIB Drs. has lead me to >> rephrase the above, please comment on 2 issues: >> >> a) situations where counters could suffer a discontinuity >> (e.g. a single OSPFv3 area's counters could have a discontinuity) >> The reason is that the document specifies only one OSPFv3 related >> reason for counters to suffer a discontinuity (i.e., the >> restart of the >> OSPFv3 >> routing process) and this is in the text of the document, not the MIB >> portion >> of the document. Describing more specific OSPFv3 situations >> in the MIB >> document itself >> would help implementors. > > The thinking was that an OSPFv3 instance would never clear its SNMP > counters after it is started, so only the coarse discontinuity > timer is necessary. I will add the text into the MIB module in > the discontinuity timer object description. Thank you. > >> >> b) some of the indexes use InterfaceIndex from the IF-MIB. >> The counters >> in these tables "might" be related to the ifCounterDiscontinuityTime >> object. >> More discussion on these tables would be helpful to determine if this >> is so. > > The ifCounterDiscontinuityTime does not apply to the counters associated > with OSPFv3 interfaces. > Okay. I do have a couple more questions, is there a one-to-one mapping between an OSPFv3 Interface and an IPv6 interface? If so, then do the DiscontinuityTimeObjects in RFC4293 apply to OSPFv3 interfaces as well? More generally, does the IP-MIB in RFC4293 need to be populated prior to this MIB? -Joan >> >> In essence, more Discontinuity objects may NOT be beneficial, and so >> would like to discuss a) and b) above before making that >> determination. >> >> Thanks, >> -Joan >> > [snip to end] > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Mar 19 11:12:14 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 50BAF28C68C; Wed, 19 Mar 2008 11:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.174 X-Spam-Level: X-Spam-Status: No, score=-100.174 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 keN8BGEwuF1j; Wed, 19 Mar 2008 11:12:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B09E3A6A7B; Wed, 19 Mar 2008 11:11:52 -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 F13DC3A6CC0 for ; Wed, 19 Mar 2008 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ptGq-XKwOGcV for ; Wed, 19 Mar 2008 11:11:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 338443A6A20 for ; Wed, 19 Mar 2008 11:10:13 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m2JI7ok2013853 for ; Wed, 19 Mar 2008 18:07:50 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m2JI7lt1013824 for ; Wed, 19 Mar 2008 18:07:50 GMT Message-ID: <079701c889ec$22702080$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 19 Mar 2008 18:06:14 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [OSPF] CCAMP last call on advertisement of inter-AS TE links X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi, You may recall providing useful review and feedback on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-02.txt The authors believe that they have taken on board all the comments received from the OSPF working group and have updated the draft accordingly. CCAMP is holding a three week working group last call on this I-D along with its IS-IS partner document: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-00.txt These documents describe how to advertise the TE links that connect an AS to the outside world within the AS's IGP. As the drafts are at pains to point out, there is no proposal to advertise the TE information more widely (such as to other ASes). The last call will end at 12 noon BST on April 9th 2008. Please send your comments to the CCAMP list or direct to the CCAMP chairs. Thanks, Adrian and Deborah _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From shoeshinesos@papilloncanada.com Thu Mar 20 00:52:46 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 E08B928C133 for ; Thu, 20 Mar 2008 00:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.884 X-Spam-Level: **** X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7J5Qoksjr4P for ; Thu, 20 Mar 2008 00:52:46 -0700 (PDT) Received: from p5493BA89.dip0.t-ipconnect.de (p5493BA89.dip0.t-ipconnect.de [84.147.186.137]) by core3.amsl.com (Postfix) with ESMTP id 917EF28C243 for ; Thu, 20 Mar 2008 00:52:45 -0700 (PDT) Message-ID: <01c88a67$72106200$89ba9354@shoeshinesos> From: "Odell Neal" To: Subject: Office 2007 Enterprise ready to download Date: Thu, 20 Mar 2008 08:50:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 X-Spam: Not detected Microsoft Office Enterprise 2007 includes: • Access 2007 • Communicator 2007 • Excel 2007 • Groove 2007 • InfoPath 2007 • OneNote 2007 • Outlook 2007 • PowerPoint 2007 • Publisher 2007 • Word 2007 http://terrycuttingfe421.blogspot.com System Requirements • Intel® Pentium® or AMD® 500 MHz processor • Microsoft Windows® XP Professional or Home Edition with Service Pack 2, Windows Server® 2003 with SP1, Microsoft Windows Vista. • 256 Mb of RAM • 2GB of available hard-disk space. • 1024x768 or higher resolution monitor • Some features require Microsoft Windows Desktop Search 3.0, Microsoft Windows Media Player 9.0, Microsoft DirectX 9.0b, Microsoft Active Sync 4.1 From ospf-bounces@ietf.org Thu Mar 20 13:04: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 91A953A6F76; Thu, 20 Mar 2008 13:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 nSCIvpbvY0To; Thu, 20 Mar 2008 13:04:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B905F3A6BA2; Thu, 20 Mar 2008 13:04:49 -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 AC6C33A6B0B for ; Thu, 20 Mar 2008 13:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 gpdLXKT8KX42 for ; Thu, 20 Mar 2008 13:04:44 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 8711F3A6BA2 for ; Thu, 20 Mar 2008 13:04:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 56F8C1812F0 for ; Thu, 20 Mar 2008 13:02:27 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13122-10 for ; Thu, 20 Mar 2008 13:02:27 -0700 (PDT) Received: from [JC?????IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 0430A1812EE for ; Thu, 20 Mar 2008 13:02:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: OSPF List From: Acee Lindem Date: Thu, 20 Mar 2008 16:02:19 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] Dynamic Hostname Exchange Mechanism for OSPF - draft-venkata-ospf-dynamic-hostname-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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This draft was presented in Vancouver and with an update in Philadelphia. At both WG meetings there was interest in making this a WG document and no opposition. Is there any one now who has a compelling reason why this should not be a WG document? If not, I plan to have the authors submit it as a WG document on Monday. Note that there will be plenty of time to comment on the technical contents of the draft. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 20 14:21:46 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 961A028C6BE; Thu, 20 Mar 2008 14:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.364 X-Spam-Level: X-Spam-Status: No, score=-100.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 NNvQ1cAqsOFS; Thu, 20 Mar 2008 14:21:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B41B28C4A4; Thu, 20 Mar 2008 14:21:45 -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 BAD6328C4A4 for ; Thu, 20 Mar 2008 14:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 VHtJKH0V3-kj for ; Thu, 20 Mar 2008 14:21:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 9EE3228C2F4 for ; Thu, 20 Mar 2008 14:21:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m2KLJDgj018750 for ; Thu, 20 Mar 2008 21:19:18 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m2KLJBjH018740 for ; Thu, 20 Mar 2008 21:19:12 GMT Message-ID: <0a0d01c88ad0$095d4fc0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "OSPF List" References: Date: Thu, 20 Mar 2008 21:19:07 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [OSPF] Dynamic Hostname Exchange Mechanism for OSPF -draft-venkata-ospf-dynamic-hostname-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Acee, I missed the last two OSPF meetings because of agenda clashes, and I haven't seen much discussion on the list. I support the idea of being able to exchange a textual name for routers, and having this I-D in the working group may provide a way to get the mechanism right. I am worried as Nitin was about the idea of using the RI LSA since the name of a router is not a router capability. And we wouldn't want the 255 byte reflooded every time some other routing capability was modified. Indeed, the consumer of the router name is unlikely to be the IP routing and forwarding component. So the information should be moved to some other LSA that can be handled with different refresh rules and potentially moved into a separate OSPF instance per I note that you said > This isn't the type of information we are envisioning needing > to be split out. It is only a single name and will be an optional > TLV for an existing LSA. The separate instance would be > more for flooding larger volumes of non-routing information > associated with new applications (once we have this instance, > it also would be nice to move some existing opaque LSAs to > it as well). The fact that it is optional for an LSA, doesn't seem relevant. Once it is in the LSA it has to be flooded. Additionally, this could well be the thin end of the wedge. Wouldn't it be useful for network management tools if the routers flooded some geographical coordinate? Wouldn't it be handy for operators if the postal address and phone number of the maintenance site were flooded? Where will this lead? Take the clean approach now. Recognise that information not used for IP routing does not belong in the primary instance of the IGP. So, I guess I give you a qualified "yes" to your question. Make this a WG ID if the debate about moving the information out of the RI LSA is still open. Cheers, Adrian ----- Original Message ----- From: "Acee Lindem" To: "OSPF List" Sent: Thursday, March 20, 2008 8:02 PM Subject: [OSPF] Dynamic Hostname Exchange Mechanism for OSPF -draft-venkata-ospf-dynamic-hostname-02.txt > This draft was presented in Vancouver and with an update in > Philadelphia. At both WG meetings there was interest in making this a > WG document and no opposition. Is there any one now who has a > compelling reason why this should not be a WG document? If not, I > plan to have the authors submit it as a WG document on Monday. Note > that there will be plenty of time to comment on the technical > contents of the draft. > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Mar 20 15:13:00 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 DD27428C7A9; Thu, 20 Mar 2008 15:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 SJWXTDVyZOYR; Thu, 20 Mar 2008 15:12:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3EA28C78C; Thu, 20 Mar 2008 15:12:56 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1C03A6F5A for ; Thu, 20 Mar 2008 15:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 9foaRuqz4ITU for ; Thu, 20 Mar 2008 15:12:54 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id F04D628C272 for ; Thu, 20 Mar 2008 15:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4E9F9632B1D; Thu, 20 Mar 2008 15:10:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06902-10; Thu, 20 Mar 2008 15:10:34 -0700 (PDT) Received: from [????????p??????$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 14F90C58E09; Thu, 20 Mar 2008 15:10:24 -0700 (PDT) In-Reply-To: <0a0d01c88ad0$095d4fc0$0200a8c0@your029b8cecfe> References: <0a0d01c88ad0$095d4fc0$0200a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Acee Lindem Date: Thu, 20 Mar 2008 18:10:23 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] Dynamic Hostname Exchange Mechanism for OSPF -draft-venkata-ospf-dynamic-hostname-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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Adrian, Historically, the draft/RFC is titled router capabilities but you'll note that the actual name of the LSA is the RI (Router Information LSA). I do believe that the system name fits in the category of information and it WILL be used in OSPF for routing - not directly for calculating OSPF routes but for debugging networks when routing doesn't work. Hence, IMHO, it satisfies both the criteria for inclusion in the default instance and the criteria for inclusion in the OSPF RI LSA. Like most of the other information in the RI LSA, I'd expect it be fairly static. Thanks, Acee On Mar 20, 2008, at 5:19 PM, Adrian Farrel wrote: > Acee, > > I missed the last two OSPF meetings because of agenda clashes, and > I haven't > seen much discussion on the list. > > I support the idea of being able to exchange a textual name for > routers, and > having this I-D in the working group may provide a way to get the > mechanism > right. > > I am worried as Nitin was about the idea of using the RI LSA since > the name > of a router is not a router capability. And we wouldn't want the > 255 byte > reflooded every time some other routing capability was modified. > Indeed, the > consumer of the router name is unlikely to be the IP routing and > forwarding > component. So the information should be moved to some other LSA > that can be > handled with different refresh rules and potentially moved into a > separate > OSPF instance per > > I note that you said >> This isn't the type of information we are envisioning needing >> to be split out. It is only a single name and will be an optional >> TLV for an existing LSA. The separate instance would be >> more for flooding larger volumes of non-routing information >> associated with new applications (once we have this instance, >> it also would be nice to move some existing opaque LSAs to >> it as well). > > The fact that it is optional for an LSA, doesn't seem relevant. > Once it is > in the LSA it has to be flooded. > > Additionally, this could well be the thin end of the wedge. > Wouldn't it be > useful for network management tools if the routers flooded some > geographical > coordinate? Wouldn't it be handy for operators if the postal > address and > phone number of the maintenance site were flooded? Where will this > lead? > > Take the clean approach now. Recognise that information not used > for IP > routing does not belong in the primary instance of the IGP. > > So, I guess I give you a qualified "yes" to your question. Make > this a WG ID > if the debate about moving the information out of the RI LSA is > still open. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Acee Lindem" > To: "OSPF List" > Sent: Thursday, March 20, 2008 8:02 PM > Subject: [OSPF] Dynamic Hostname Exchange Mechanism for > OSPF -draft-venkata-ospf-dynamic-hostname-02.txt > > >> This draft was presented in Vancouver and with an update in >> Philadelphia. At both WG meetings there was interest in making this a >> WG document and no opposition. Is there any one now who has a >> compelling reason why this should not be a WG document? If not, I >> plan to have the authors submit it as a WG document on Monday. Note >> that there will be plenty of time to comment on the technical >> contents of the draft. >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 21 06:35:31 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 6DEF23A6D45; Fri, 21 Mar 2008 06:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.458 X-Spam-Level: X-Spam-Status: No, score=-100.458 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 zN+LEZk+Ugkb; Fri, 21 Mar 2008 06:35:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916763A6C5C; Fri, 21 Mar 2008 06:35:30 -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 C436C28C128 for ; Fri, 21 Mar 2008 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 YS1zccyNVDJl for ; Fri, 21 Mar 2008 06:35:24 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 763603A692F for ; Fri, 21 Mar 2008 06:35:24 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D7EC72680A3; Fri, 21 Mar 2008 07:33:06 -0600 (MDT) Received: from [172.27.200.235] (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for ospf@ietf.org; Fri, 21 Mar 2008 07:33:06 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <4756CD7B-95FD-4014-9A3B-C7B2795D8323@tcb.net> From: Danny McPherson To: OSPF List In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) X-Priority: 3 Date: Fri, 21 Mar 2008 07:32:47 -0600 References: <0a0d01c88ad0$095d4fc0$0200a8c0@your029b8cecfe> X-Mailer: Apple Mail (2.919.2) Subject: Re: [OSPF] Dynamic Hostname Exchange Mechanism for OSPF -draft-venkata-ospf-dynamic-hostname-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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org On Mar 20, 2008, at 4:10 PM, Acee Lindem wrote: > Hi Adrian, > > Historically, the draft/RFC is titled router capabilities but you'll > note that the actual name of the LSA is the RI (Router Information > LSA). I do believe that the system name fits in the category of > information and it WILL be used in OSPF for routing - not directly > for calculating OSPF routes but for debugging networks when routing > doesn't work. Hence, IMHO, it satisfies both the criteria for > inclusion in the default instance and the criteria for inclusion in > the OSPF RI LSA. Like most of the other information in the RI LSA, > I'd expect it be fairly static. And this is indeed why it's been defined as such. -danny _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 21 09:25: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 B301F28C26F; Fri, 21 Mar 2008 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.636 X-Spam-Level: X-Spam-Status: No, score=-100.636 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 f3K5TmRJDJ4u; Fri, 21 Mar 2008 09:25:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7870E3A6AE1; Fri, 21 Mar 2008 09:25:42 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A26F3A6997 for ; Fri, 21 Mar 2008 09:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 PeRsut1VaUYZ for ; Fri, 21 Mar 2008 09:25:37 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id B86CA3A6831 for ; Fri, 21 Mar 2008 09:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4477971B86B for ; Fri, 21 Mar 2008 09:23:20 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03011-09 for ; Fri, 21 Mar 2008 09:23:20 -0700 (PDT) Received: from [JC?????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E8D9E71B86A for ; Fri, 21 Mar 2008 09:23:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) To: OSPF List Message-Id: From: Acee Lindem Date: Fri, 21 Mar 2008 12:23:19 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] IETF 71 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-Type: multipart/mixed; boundary="===============0279522215==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0279522215== Content-Type: multipart/alternative; boundary=Apple-Mail-4-176132567 --Apple-Mail-4-176132567 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Please unicast corrections to me. If you want to discuss a specific topic, please start a thread on this list with the specific topic as the subject (this will make searching the archives easier). http://www.ietf.org/proceedings/08mar/minutes/ospf.txt Thanks, Acee --Apple-Mail-4-176132567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Please unicast corrections = to me. =A0If you want to discuss a specific topic, please start a thread = on this list with the specific topic as the subject (this will make = searching the archives easier).=A0


Thanks,
Acee
= --Apple-Mail-4-176132567-- --===============0279522215== 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 --===============0279522215==-- From ospf-bounces@ietf.org Fri Mar 21 11:39:25 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 526AC28C405; Fri, 21 Mar 2008 11:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 f8m9QyJ618IE; Fri, 21 Mar 2008 11:39:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844A528C25E; Fri, 21 Mar 2008 11:38:26 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A4928C249 for ; Fri, 21 Mar 2008 11:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ta62jCmlUFRm for ; Fri, 21 Mar 2008 11:38:19 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 0FFB628C15F for ; Fri, 21 Mar 2008 11:38:17 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m2LIIKo4013172; Fri, 21 Mar 2008 19:18:20 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Mar 2008 19:35:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 19:35:36 +0100 Message-ID: <00275A5B436CA441900CB10936742A384EC92D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] IETF 71 OSPF WG Minutes Thread-Index: AciLb+6sh360AiA0T5qtodrG35wFygAB728A References: From: "PAPADIMITRIOU Dimitri" To: "Acee Lindem" , "OSPF List" X-OriginalArrivalTime: 21 Mar 2008 18:35:54.0831 (UTC) FILETIME=[65B32DF0:01C88B82] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OSPF] IETF 71 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org acee, > Question regarding PW3 document (Andrew's draft) > Acee - not a big fan > Dave Ward - have the authors give another presentation > Dimitri Papadimitriou - What is holdup? add: comments raised were addressed (e.g. possibility to segment between instances when solution will be made available by OSPF WG see Section 5.3). > Acee - Number of people didn't like it, but we are deferring to > PW3 group. Now it seems that PW3 is supporting it so can bring > it back to OSPF WG for consideration. side note: i would like to keep the discussion at the technical level if any remaining - ping-pong between working groups do not help solving them. > Multi-instance / Transport Instance Draft - Acee (See Slides) > > Will be pushing harder for this, discuss on list add (if my record is correct, you stated also that): the working group will open the floor for alternative solutions once the problem statement will be refined further than a brief overview introduction (as it is the case in this v00 of the document). thanks, -d. > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > Behalf Of Acee Lindem > Sent: Friday, March 21, 2008 5:23 PM > To: OSPF List > Subject: [OSPF] IETF 71 OSPF WG Minutes > > Please unicast corrections to me. If you want to discuss a > specific topic, please start a thread on this list with the > specific topic as the subject (this will make searching the > archives easier). > > > http://www.ietf.org/proceedings/08mar/minutes/ospf.txt > > > Thanks, > Acee > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Mar 21 14:44:54 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 6EE2728C4B3; Fri, 21 Mar 2008 14:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 BqWLso0x+nvK; Fri, 21 Mar 2008 14:44:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77ED73A6CAF; Fri, 21 Mar 2008 14:44:53 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B14F28C26A; Fri, 21 Mar 2008 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 4H5SGP8vEgkh; Fri, 21 Mar 2008 14:44:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EA37B3A6925; Fri, 21 Mar 2008 14:44:48 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2LLgQg03522; Fri, 21 Mar 2008 21:42:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 17:41:40 -0400 Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501413B24AC7@zrtphxm1.corp.nortel.com> In-Reply-To: <00d801c888ad$5ae647e0$6601a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt thread-index: AciIrWFBoIwWf7itRmSWUrKrZbhArAC4aMgQ References: <00d801c888ad$5ae647e0$6601a8c0@JoanPC> From: "Daniel Joyal" To: "Joan Cucchiara" , "Romascanu, Dan (Dan)" , "Acee Lindem" , , "MIB Doctors (E-mail)" Cc: Vishwas Manral , Ronald Bonica , Ross Callon , Bert Wijnen Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org [snip] > > > > Since it's not mandatory, do many MIB authors opt to add a > read-only > > conformance? In other words, is it common practice? > > > > Yes, it is common practice. Then we will follow doctor's advice ;-) > > > >> > >> b) some of the indexes use InterfaceIndex from the IF-MIB. > >> The counters > >> in these tables "might" be related to the > ifCounterDiscontinuityTime > >> object. > >> More discussion on these tables would be helpful to > determine if this > >> is so. > > > > The ifCounterDiscontinuityTime does not apply to the counters > > associated with OSPFv3 interfaces. > > > > Okay. I do have a couple more questions, is there a > one-to-one mapping between an OSPFv3 Interface and an IPv6 interface? > If so, then do the DiscontinuityTimeObjects in RFC4293 apply > to OSPFv3 interfaces as well? There is a one-to-one relationship for non-virtual interfaces, but the OSPFv3 interface should survive a recycling of the lower layer interface, that is, recycling of the lower layer interface should not cause an OSPFv3 interface to clear its SNMP counters. > > More generally, does the IP-MIB in RFC4293 need to be > populated prior to this MIB? In general, there should be a corresponding entry in the ipv6InterfaceTable from the IP-MIB for non-virtual OSPFv3 interfaces, but I think the dependency of the configuration of an OSPFv3 interface upon the configuration of an IPv6 interface would be implementation specific. Thanks. -Dan > > -Joan > > > > >> > >> In essence, more Discontinuity objects may NOT be > beneficial, and so > >> would like to discuss a) and b) above before making that > >> determination. > >> > >> Thanks, > >> -Joan > >> > > [snip to end] > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Mar 24 23:02:59 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 084273A69B3; Mon, 24 Mar 2008 23:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.706 X-Spam-Level: X-Spam-Status: No, score=-100.706 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 0Z14zSlRUOJo; Mon, 24 Mar 2008 23:02:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC683A6A84; Mon, 24 Mar 2008 23:02:57 -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 59F8C3A69B3 for ; Mon, 24 Mar 2008 23:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 WbUgpT3mKPHg for ; Mon, 24 Mar 2008 23:02:55 -0700 (PDT) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.245]) by core3.amsl.com (Postfix) with ESMTP id 621213A67EB for ; Mon, 24 Mar 2008 23:02:55 -0700 (PDT) Received: by hs-out-0708.google.com with SMTP id 4so2492647hsl.5 for ; Mon, 24 Mar 2008 23:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=TKs6o56O5UkUgIn9P+fIOe1dHH8Kcdo7LklmYuEFvgU=; b=qFiGNy2cbrMLoda7Q2TojKntkkPjHYgg7kFUsf8uNVNeey38Fan7qUssADnwGrjIS811JK0XQ5OFfOgqECvrMcEtlOZjID46UX6G7uIiqXXp7I1FhVFzxmowGcjgSJJLtLsVwLMeosMa9CM/tpokQPEUYvjzgo1LNfSRJ+PXcJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=ZfbpwegVrX3dDJ8CleJA/xH7XsBdRcFQ0zJummN8RA5TK+5TB6wXDfRR9CgAwDEUzzb7SaZkq/UfuBk4KByrDEPx359Vu225ubLolGCsb0IeVcVGZiC5cbHFummnofmlxwRKdXVx+lZfRWCBTl1v2vDStP5nJYatoUZHuNZT+h8= Received: by 10.115.75.1 with SMTP id c1mr13385656wal.84.1206424835180; Mon, 24 Mar 2008 23:00:35 -0700 (PDT) Received: by 10.114.135.15 with HTTP; Mon, 24 Mar 2008 23:00:35 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 11:30:35 +0530 From: "pavan bhat" To: ospf@ietf.org MIME-Version: 1.0 Subject: [OSPF] incremental spf 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="===============1115694903==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1115694903== Content-Type: multipart/alternative; boundary="----=_Part_15975_23882489.1206424835174" ------=_Part_15975_23882489.1206424835174 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hi i wanted to know how to go about implementing incremental spf pointers to any documents ? thanks pavan ------=_Part_15975_23882489.1206424835174 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
hi
 
i wanted to know how to go about implementing incremental spf
pointers to any documents ?
 
thanks
 
pavan
 
------=_Part_15975_23882489.1206424835174-- --===============1115694903== 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 --===============1115694903==-- From michael.schaefer@delta.com Sun Mar 30 21:53:07 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 EDE4E3A6B56 for ; Sun, 30 Mar 2008 21:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.987 X-Spam-Level: X-Spam-Status: No, score=-86.987 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, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URI_NOVOWEL=1.62, 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 JxH7oRslDCFr for ; Sun, 30 Mar 2008 21:53:07 -0700 (PDT) Received: from adsl-72-50-68-23.prtc.net (adsl-64-237-225-129.prtc.net [64.237.225.129]) by core3.amsl.com (Postfix) with SMTP id E07003A6ADE for ; Sun, 30 Mar 2008 21:53:06 -0700 (PDT) Received: from cxbp ([125.225.64.198]) by adsl-72-50-68-23.prtc.net (8.13.4/8.13.4) with SMTP id m2V4uG9N079727; Sun, 30 Mar 2008 20:56:16 -0800 Message-ID: <47F06E27.8020404@delta.com> Date: Sun, 30 Mar 2008 20:52:55 -0800 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: Need help in bed? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The best way to please your woman! http://zchtpcklbfgvyu.blogspot.com From ospf-bounces@ietf.org Mon Mar 31 10:36:34 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60CD3A6994; Mon, 31 Mar 2008 10:36: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 373CF3A6AB7 for ; Mon, 31 Mar 2008 10:36: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 YSWAfnjAy4lY for ; Mon, 31 Mar 2008 10:36:33 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 642763A6994 for ; Mon, 31 Mar 2008 10:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0BA1675236E; Mon, 31 Mar 2008 10:36:32 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08841-02; Mon, 31 Mar 2008 10:36:31 -0700 (PDT) Received: from [???????IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2B7F975236D; Mon, 31 Mar 2008 10:36:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Mon, 31 Mar 2008 13:36:31 -0400 To: OSPF List X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: Ross Callon , Alan Davey , CCAMP List , Vishwas Manral Subject: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv3-traffic-10.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="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org We've WG last called this draft in the past and we're going to do it again now. After some deliberations we've made the decision to go forward with this document with the two existing implementations and forgo the request for interoperability testing. The WG last call will be begin today and end April 15, 2008 at 12:00 AM EDT. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf