From asmirnov@cisco.com Thu Dec 9 14:19:24 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C9E28C136 for ; Thu, 9 Dec 2010 14:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95O3O89ixckj for ; Thu, 9 Dec 2010 14:19:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C01AD28C101 for ; Thu, 9 Dec 2010 14:19:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oB9Lvv9Z000973; Thu, 9 Dec 2010 22:57:57 +0100 (CET) Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oB9LvuVt012398; Thu, 9 Dec 2010 22:57:56 +0100 (CET) Message-ID: <4D0150FD.8090904@cisco.com> Date: Thu, 09 Dec 2010 22:58:21 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101026 SUSE/3.0.10 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 22:19:24 -0000 Hi Jeffrey, > We developed the solution for a real network situation It's a bit hard to see value of the proposal without knowing more about possible network scenarios where this solution may be applicable. Situations when cost to each neighbor is different usually mean that L2 paths to them are different. Bunch of separate L2 connections are grouped together and presented to OSPF on L3 as single multiaccess interface - but underneath it is L2 point-to-multipoint network. So saying that Hello packet propagation is more optimal is not true - replication is just moved from OSPF to lower level. Thinking of network solutions which could benefit from assigning different cost to each neighbor I come up with things like VPLS, Metro Ethernet. May be fixed radio networks. But these all are L2 p2mp networks. Multiaccess is just emulated and benefits of using it are ephemeral. Anton On 11/22/2010 05:36 PM, Jeffrey (Zhaohui) Zhang wrote: > Hi, > > I presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt in Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it was deferred to the mailing list on whether the problem is worth the working group effort (some who reviewed the draft agreed that the proposed solution is reasonable for the problem). > > I'd like to request folks to review the draft/slides and voice your opinion. We developed the solution for a real network situation and would like to see that it gets consensus and standardized so that more operators/vendors can benefit from this. > > Thanks. > Jeffrey > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From zzhang@juniper.net Fri Dec 10 10:35:11 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC4628C119 for ; Fri, 10 Dec 2010 10:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24jtVpPDsVjX for ; Fri, 10 Dec 2010 10:35:03 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id F3AF828C100 for ; Fri, 10 Dec 2010 10:35:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTQJzMnvzSlg6kIpoM4w+sKfLhQDALihx@postini.com; Fri, 10 Dec 2010 10:36:35 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Dec 2010 10:35:27 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 10 Dec 2010 13:35:27 -0500 From: "Jeffrey (Zhaohui) Zhang" To: Anton Smirnov Date: Fri, 10 Dec 2010 13:35:26 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuX7THTIsLDf0X/SS+0HjpyDmwoWwAqjXug Message-ID: <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net> <4D0150FD.8090904@cisco.com> In-Reply-To: <4D0150FD.8090904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 18:35:15 -0000 Aton, > -----Original Message----- > From: Anton Smirnov [mailto:asmirnov@cisco.com]=20 > Sent: Thursday, December 09, 2010 4:58 PM > To: Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > Hi Jeffrey, >=20 > > We developed the solution for a real network situation It is difficult to go into too much details, but there are real examples of= true-broadcast radio networks where the bw/delay is different between diff= erent pairs of radios. >=20 > It's a bit hard to see value of the proposal without knowing=20 > more about > possible network scenarios where this solution may be applicable. > Situations when cost to each neighbor is different usually=20 > mean that L2 > paths to them are different. Bunch of separate L2 connections are > grouped together and presented to OSPF on L3 as single multiaccess > interface - but underneath it is L2 point-to-multipoint network. So > saying that Hello packet propagation is more optimal is not true - > replication is just moved from OSPF to lower level. Even so you still have the benefit of reduced number of adjacencies. >=20 > Thinking of network solutions which could benefit from assigning > different cost to each neighbor I come up with things like VPLS, Metro > Ethernet. May be fixed radio networks. But these all are L2 p2mp > networks. Multiaccess is just emulated and benefits of using it are > ephemeral. Multiacess could be emulated in such a way that minimum replication happens= - in that case the benefit is real. The key is that the lower layer is presented to L3 as multi-access and we c= ould/should take advantage of it. Thanks. Jeffrey >=20 > Anton >=20 >=20 > On 11/22/2010 05:36 PM, Jeffrey (Zhaohui) Zhang wrote: > > Hi, > >=20 > > I presented the draft=20 > http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 .txt in Beijing (slides > http://www.ietf.org/proceedings/79/slides/ospf-9.= ppt) and it=20 > was deferred to the mailing list on whether the problem is=20 > worth the working group effort (some who reviewed the draft=20 > agreed that the proposed solution is reasonable for the problem). > >=20 > > I'd like to request folks to review the draft/slides and=20 > voice your opinion. We developed the solution for a real=20 > network situation and would like to see that it gets=20 > consensus and standardized so that more operators/vendors can=20 > benefit from this. > >=20 > > Thanks. > > Jeffrey > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > = From aretana@cisco.com Mon Dec 13 12:45:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E4228C112 for ; Mon, 13 Dec 2010 12:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY9M0uniSDoY for ; Mon, 13 Dec 2010 12:45:35 -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 858BC28C0F4 for ; Mon, 13 Dec 2010 12:45:35 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIsVBk2tJV2b/2dsb2JhbACkCXioFptJhUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,337,1288569600"; d="scan'208";a="192581826" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 13 Dec 2010 20:46:54 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDKksXM031624; Mon, 13 Dec 2010 20:46:54 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 14:46:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 14:46:44 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F643203E56B2D@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuX7THTIsLDf0X/SS+0HjpyDmwoWwAqjXugAJpLwfA= References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net><4D0150FD.8090904@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> From: "Alvaro Retana (aretana)" To: "Jeffrey (Zhaohui) Zhang" X-OriginalArrivalTime: 13 Dec 2010 20:46:53.0921 (UTC) FILETIME=[DFEDE510:01CB9B06] Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 20:45:36 -0000 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Jeffrey (Zhaohui) Zhang Jeffrey: Hi! ... > It is difficult to go into too much details, but there are real > examples of true-broadcast radio networks where the bw/delay is > different between different pairs of radios. It is very tempting to use the model that you describe, but radio networks can be "flimsy" because of interference, signal fading, movement, etc.. The broadcast model for neighbor discovery/maintenance can quickly become unusable for nodes that loose connectivity to the DR. It is very easy to see how the same L2 media may provide nodes that don't have the same view of the other nodes (not everyone is within radio range of everyone else, for example). This brings me to wanting to establish p2p adjacencies while using the broadcast capabilities of the media to reach whoever is within transmission range (to propagate Hellos and to flood LSAs). The recognition that the characteristics between nodes can be different should also result in the recognition that the adjacencies between pairs of nodes may not all have the same state at the same time. My 1c. Alvaro. From zzhang@juniper.net Mon Dec 20 12:18:56 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EDE3A68B6 for ; Mon, 20 Dec 2010 12:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA0-FXwrunqy for ; Mon, 20 Dec 2010 12:18:55 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 216F03A68A4 for ; Mon, 20 Dec 2010 12:18:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTQ+6oW+6LUT19KgyfBTCmfyfVe1bUD4d@postini.com; Mon, 20 Dec 2010 12:20:50 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 20 Dec 2010 12:17:48 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 20 Dec 2010 15:17:47 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" Date: Mon, 20 Dec 2010 15:17:46 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuX7THTIsLDf0X/SS+0HjpyDmwoWwAqjXugAJpLwfABYC3RAA== Message-ID: <13205C286662DE4387D9AF3AC30EF456B03AA361C3@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net><4D0150FD.8090904@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643203E56B2D@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F643203E56B2D@XMB-RCD-206.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:18:56 -0000 Alvaro, Sorry for the late response. Please see below.=20 > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 > Sent: Monday, December 13, 2010 3:47 PM > To: Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of > > Jeffrey (Zhaohui) Zhang >=20 > Jeffrey: >=20 > Hi! >=20 > ... > > It is difficult to go into too much details, but there are real > > examples of true-broadcast radio networks where the bw/delay is > > different between different pairs of radios. >=20 > It is very tempting to use the model that you describe, but radio > networks can be "flimsy" because of interference, signal fading, > movement, etc.. The broadcast model for neighbor=20 > discovery/maintenance > can quickly become unusable for nodes that loose connectivity=20 > to the DR. > It is very easy to see how the same L2 media may provide nodes that > don't have the same view of the other nodes (not everyone is within > radio range of everyone else, for example). There are real-life examples where a radio network is built to guarantee th= at if a node can reach a central node then it can reach others who can also= reach the central node (e.g., a satellite network). A node's transimission= /receiving capability can be impacted by its placement, but the broadcast p= roperty of the network is still maintained (if a station is so out of place= then it is considered off the network, just like a cable is cut in the wir= ed ethernet case). The premise is that we have a broadcast network but one can reach some stat= ions with a metric that is different from when reaching others. If that premise is not satisfied, then it's a different topic (and out of t= he scope). Thanks. Jeffrey >=20 > This brings me to wanting to establish p2p adjacencies while using the > broadcast capabilities of the media to reach whoever is within > transmission range (to propagate Hellos and to flood LSAs). The > recognition that the characteristics between nodes can be different > should also result in the recognition that the adjacencies=20 > between pairs > of nodes may not all have the same state at the same time. >=20 > My 1c. >=20 > Alvaro. >=20 > = From aretana@cisco.com Mon Dec 20 12:43:05 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474773A6AEA for ; Mon, 20 Dec 2010 12:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vICqueB3aBEu for ; Mon, 20 Dec 2010 12:43:04 -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 584BB3A68C3 for ; Mon, 20 Dec 2010 12:43:04 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABpPD02tJXHA/2dsb2JhbACkG3OjYJtDhUkEhGWJOQ X-IronPort-AV: E=Sophos;i="4.60,203,1291593600"; d="scan'208";a="195280169" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2010 20:44:58 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id oBKKiwuv001966; Mon, 20 Dec 2010 20:44:58 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Dec 2010 14:44:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2010 14:44:36 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F643203FC1901@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03AA361C3@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuX7THTIsLDf0X/SS+0HjpyDmwoWwAqjXugAJpLwfABYC3RAAAAzbtQ References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net><4D0150FD.8090904@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643203E56B2D@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03AA361C3@EMBX01-WF.jnpr.net> From: "Alvaro Retana (aretana)" To: "Jeffrey (Zhaohui) Zhang" X-OriginalArrivalTime: 20 Dec 2010 20:44:57.0708 (UTC) FILETIME=[C38D72C0:01CBA086] Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:43:05 -0000 > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Monday, December 20, 2010 3:18 PM Jeffrey: ... > > It is very tempting to use the model that you describe, but radio > > networks can be "flimsy" because of interference, signal fading, > > movement, etc.. The broadcast model for neighbor > > discovery/maintenance can quickly become unusable for nodes that > > loose connectivity to the DR. > > > > It is very easy to see how the same L2 media may provide nodes that > > don't have the same view of the other nodes (not everyone is within > > radio range of everyone else, for example). >=20 > There are real-life examples where a radio network is built to > guarantee that if a node can reach a central node then it can reach > others who can also reach the central node (e.g., a satellite network). That's transitive connectivity (nodes can reach each other through the satellite), not direct connectivity (a node sends a broadcast and others receive it w/out any other node in the middle). ...but that could be a completely separate discussion. ;-) ... > The premise is that we have a broadcast network but one can reach some > stations with a metric that is different from when reaching others. >=20 > If that premise is not satisfied, then it's a different topic (and out > of the scope). You should specifically mention the limitations of the solution in the draft to avoid generalizations...like the one I made when you suggested "radio networks". Happy Holidays!! Alvaro. From zzhang@juniper.net Mon Dec 20 12:48:53 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C50D3A6AEC for ; Mon, 20 Dec 2010 12:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9bvn7JzId29 for ; Mon, 20 Dec 2010 12:48:52 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 0B8823A6AEB for ; Mon, 20 Dec 2010 12:48:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTQ/BpkFRbKc5twFRtC78+Dvi7TF3prYL@postini.com; Mon, 20 Dec 2010 12:50:47 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 20 Dec 2010 12:48:16 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 20 Dec 2010 15:48:15 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" Date: Mon, 20 Dec 2010 15:48:14 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcuX7THTIsLDf0X/SS+0HjpyDmwoWwAqjXugAJpLwfABYC3RAAAAzbtQAACg4CA= Message-ID: <13205C286662DE4387D9AF3AC30EF456B03AA36275@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B028963031@EMBX01-WF.jnpr.net><4D0150FD.8090904@cisco.com> <13205C286662DE4387D9AF3AC30EF456B02F134A8E@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643203E56B2D@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03AA361C3@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643203FC1901@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F643203FC1901@XMB-RCD-206.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:48:53 -0000 Alvaro, The transitive connectivity is at l2 level though :-) I will emphasize that fact that the premise is a broadcast network. Thanks. Jeffrey > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 > Sent: Monday, December 20, 2010 3:45 PM > To: Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Monday, December 20, 2010 3:18 PM >=20 >=20 > Jeffrey: >=20 >=20 > ... > > > It is very tempting to use the model that you describe, but radio > > > networks can be "flimsy" because of interference, signal fading, > > > movement, etc.. The broadcast model for neighbor > > > discovery/maintenance can quickly become unusable for nodes that > > > loose connectivity to the DR. > > > > > > It is very easy to see how the same L2 media may provide=20 > nodes that > > > don't have the same view of the other nodes (not everyone=20 > is within > > > radio range of everyone else, for example). > >=20 > > There are real-life examples where a radio network is built to > > guarantee that if a node can reach a central node then it can reach > > others who can also reach the central node (e.g., a satellite > network). >=20 > That's transitive connectivity (nodes can reach each other through the > satellite), not direct connectivity (a node sends a broadcast=20 > and others > receive it w/out any other node in the middle). >=20 > ...but that could be a completely separate discussion. ;-) >=20 >=20 > ... > > The premise is that we have a broadcast network but one can=20 > reach some > > stations with a metric that is different from when reaching others. > >=20 > > If that premise is not satisfied, then it's a different=20 > topic (and out > > of the scope). >=20 > You should specifically mention the limitations of the solution in the > draft to avoid generalizations...like the one I made when you=20 > suggested > "radio networks". >=20 > Happy Holidays!! >=20 > Alvaro. >=20 > = From p6c6d6@gmail.com Mon Dec 20 19:58:02 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA11E3A67EE for ; Mon, 20 Dec 2010 19:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 flZUBtYLfZ9t for ; Mon, 20 Dec 2010 19:58:02 -0800 (PST) Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by core3.amsl.com (Postfix) with ESMTP id 05BB83A67BD for ; Mon, 20 Dec 2010 19:58:01 -0800 (PST) Received: by pzk9 with SMTP id 9so2101802pzk.15 for ; Mon, 20 Dec 2010 19:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PyNGIq+u2zC8rIcauw8cbapREGh6stku4CyCd64FoLU=; b=mtnSy80EGxJGem5fZYiDt3i1BkgRvn9baymmAzM+mxJZYOSzzDR9soksMLUhS9kd6c tqw8pEEAqjJgbg7ZiFn+xIpRowdAgFDlX+e0wcIDFgF20An6FbewK8fYkbdVaPiFWEYN l4eZt2U94p4M6sYyKYicaqvtztlCeGWqtdyCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mGf4LUFfjrYHWrCHVvRI6+4W+JLBxivv4NorcuaDg6ANKSpESJ1x9elD320sdUX2Xi f1P//FhFnfMBaJO1cyYWnIXeVU888YUzniwFr5xsa4bnwTyOGHvhMwMo3biH/P1LSVU7 Acedc4sdEJOdW5xAV5fQp16CGfr5qXdOy1ngw= MIME-Version: 1.0 Received: by 10.143.36.16 with SMTP id o16mr4137627wfj.45.1292903997114; Mon, 20 Dec 2010 19:59:57 -0800 (PST) Received: by 10.142.226.12 with HTTP; Mon, 20 Dec 2010 19:59:57 -0800 (PST) Date: Tue, 21 Dec 2010 09:29:57 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001636e8ffc67a0b4c0497e3abcd Subject: [OSPF] links stub network calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 03:58:02 -0000 --001636e8ffc67a0b4c0497e3abcd Content-Type: text/plain; charset=ISO-8859-1 hi, "links to stub networks are considered in the second stage of shortest path calculation". Is there any specific reason to do that. what happens if they are calculated in the first stage itself. please shed some light. thanks --001636e8ffc67a0b4c0497e3abcd Content-Type: text/html; charset=ISO-8859-1 hi,

"links to stub networks are considered in the second stage of
shortest path calculation". Is there any specific reason to do
that. what happens if they are calculated in the first stage itself.
please shed some light.

thanks

--001636e8ffc67a0b4c0497e3abcd-- From acee.lindem@ericsson.com Tue Dec 21 07:33:08 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83783A6B00 for ; Tue, 21 Dec 2010 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 U2KnzUGuj6s2 for ; Tue, 21 Dec 2010 07:33:08 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 32F913A6A4B for ; Tue, 21 Dec 2010 07:33:08 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oBLG7ddY030536; Tue, 21 Dec 2010 10:07:41 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.182]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 21 Dec 2010 10:35:00 -0500 From: Acee Lindem To: p6 c6d6 Date: Tue, 21 Dec 2010 10:34:58 -0500 Thread-Topic: [OSPF] links stub network calculation Thread-Index: AcuhJKDBMFb7z5yPRg6m42lYQjmZdA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] links stub network calculation X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 15:33:09 -0000 This is covered on page 167, RFC 2328: The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1]. Hope this helps, Acee On Dec 20, 2010, at 10:59 PM, p6 c6d6 wrote: hi, "links to stub networks are considered in the second stage of shortest path calculation". Is there any specific reason to do that. what happens if they are calculated in the first stage itself. please shed some light. thanks From abhishekb@huawei.com Sun Dec 26 22:22:51 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194833A6863 for ; Sun, 26 Dec 2010 22:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.109 X-Spam-Level: **** X-Spam-Status: No, score=4.109 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, TRACKER_ID=2.003] 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 Cxm6Paskm0SJ for ; Sun, 26 Dec 2010 22:22:45 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8ACA83A6862 for ; Sun, 26 Dec 2010 22:22:44 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LE200JAGPQD05@szxga05-in.huawei.com> for ospf@ietf.org; Mon, 27 Dec 2010 14:23:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LE2000N8PQDN2@szxga05-in.huawei.com> for ospf@ietf.org; Mon, 27 Dec 2010 14:23:01 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LE200KJQPQC8A@szxml06-in.huawei.com> for ospf@ietf.org; Mon, 27 Dec 2010 14:23:01 +0800 (CST) Date: Mon, 27 Dec 2010 11:53:00 +0530 From: Abhishek Bhalotia To: ospf@ietf.org Message-id: <87D57227BAA24AECA1EF195BB904AA2D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_boNd9E8jFIgWG5XiA9yKJA)" Thread-index: AculjoJK/YG9N9a1RAOqEiz5Pho5vg== Subject: [OSPF] Query for OSPFv3 MIB range value X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 06:22:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_boNd9E8jFIgWG5XiA9yKJA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have one query related to OSPFv3 MIB (rfc5643) For the below field the range is defined from 1 to 1800 Ospfv3UpToRefreshIntervalTC SYNTAX Unsigned32 (1..1800) And below is one of the many entries that are using this Syntax ospfv3NbrRestartHelperAge OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF Graceful restart interval, if the router is acting as a restart helper for the neighbor." ::= { ospfv3NbrEntry 14 } So now If Process is not HELPER enabled, and Current state of Helper is NONE. So what value must be displayed for "ospfv3NbrRestartHelperAge" ? Value 0 can not be displayed as it is not in range. This problem does not exist in OSPFv2, as no such range is specified Similar issues are present in other table entires too where the minimum value is 1 instead of 0. For eg: ospfv3NbrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The interface ID that the neighbor advertises in its Hello Packets on this link, that is, the neighbor's local interface index." ::= { ospfv3NbrEntry 12 } Here InterfaceIndex range start from 1 But in case of NBMA nbr which is created due to configuration, this field will be 0. So how to display this field ? Other similar fields are ROUTER-Id, [Interface DR/BDR values refer to Router id, and for P2P interface how to display value 0 ] Thanks and regards Abhishek **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_boNd9E8jFIgWG5XiA9yKJA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

 

I have one query related to OSPFv3 = MIB (rfc5643)

 

For the below field the range is defined from 1 to = 1800

Ospfv3UpToRefreshIntervalTC =

       &nbs=
p;     SYNTAX      =
Unsigned32 (1..1800) =

 

And below is one of the many entries that are using = this Syntax

 

   ospfv3NbrRestartHelperAge =
OBJECT-TYPE  
       &nbs=
p;   SYNTAX       =
Ospfv3UpToRefreshIntervalTC 
       &nbs=
p;   UNITS        =
"seconds"  
       &nbs=
p;   MAX-ACCESS   read-only  =

       &nbs=
p;   STATUS       =
current  
       &nbs=
p;   DESCRIPTION  =

       &nbs=
p;      "Remaining time in current =
OSPF Graceful restart  
       &nbs=
p;      interval, if the router is acting =
as a restart  
       &nbs=
p;      helper for the neighbor." =
 
       &nbs=
p;   ::=3D { ospfv3NbrEntry 14 }  =

 

So now If Process is not HELPER enabled, and Current = state of Helper is NONE.

So what value must be displayed = for  “ospfv3NbrRestartHelperAge” ?

Value 0 can not be displayed = as it is not in range.

 

This problem does not exist in OSPFv2, as no such range is = specified

 

 

Similar issues are present in other table entires too = where the minimum value is 1 instead of 0.

 

For eg:

ospfv3NbrIfId OBJECT-TYPE =

       &nbs=
p;    SYNTAX       =
;   InterfaceIndex 
       &nbs=
p;    MAX-ACCESS      =
read-only 
       &nbs=
p;    STATUS       =
;   current 
       &nbs=
p;    DESCRIPTION =

       &nbs=
p;        "The interface ID =
that the neighbor advertises 
       &nbs=
p;        in its Hello Packets =
on this link, that is, the 
       &nbs=
p;        neighbor's local =
interface index." 
       &nbs=
p;    ::=3D { ospfv3NbrEntry 12 } =

 

Here InterfaceIndex range start from = 1

But in case of NBMA nbr which is = created due to configuration, this field will be 0. So how to display this field = ?

 

Other similar fields are ROUTER-Id, [Interface DR/BDR = values refer to Router id, and for P2P interface how to display value 0 = ]

 

 

Thanks and regards

Abhishek

 

       =       *************************************************************************= **************

       =      This e-mail and attachments contain confidential information from HUAWEI, = which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by persons = other than the intended recipient's) is prohibited. If you receive this e-mail = in error, please notify the sender by phone or email immediately and delete = it!

 

--Boundary_(ID_boNd9E8jFIgWG5XiA9yKJA)-- From yasu@jaist.ac.jp Mon Dec 27 07:07:28 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C283A680B for ; Mon, 27 Dec 2010 07:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 WBaw4DeutGvx for ; Mon, 27 Dec 2010 07:07:28 -0800 (PST) Received: from mailrelayi.jaist.ac.jp (mailrelayi.jaist.ac.jp [150.65.19.7]) by core3.amsl.com (Postfix) with ESMTP id 4249F3A6804 for ; Mon, 27 Dec 2010 07:07:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,234,1291561200"; d="scan'208";a="91150185" Received: from rsd-dhcp-226.jaist.ac.jp (HELO localhost) ([150.65.47.226]) by mailrelayi.jaist.ac.jp with ESMTP; 28 Dec 2010 00:09:32 +0900 Date: Tue, 28 Dec 2010 00:09:31 +0900 (JST) Message-Id: <20101228.000931.81044378.yasu@jaist.ac.jp> To: ospf@ietf.org From: Yasuhiro Ohara Original-recipient: rfc822;yasu@jaist.ac.jp X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [OSPF] Question about 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: , X-List-Received-Date: Mon, 27 Dec 2010 15:07:28 -0000 Hi list. RFC 2328 16.1. "Calculating the shortest-path tree for an area" (3) says that: Note that when there is a choice of vertices closest to the root, network vertices must be chosen before router vertices in order to necessarily find all equal-cost paths. I couldn't think of any possible case that we fail to find all equal-cost paths when the router vertices are chosen first. Is there any ? When I first felt that I understood this, I remember that this seemed to be due to the fact that the cost is implicitly ZERO from a network vertex to a router vertex. But I can't think of any case now. Even if the network vertices are chosen later, they are added eventually, and all the equal-cost multipaths are correctly calculated. Would someone please explain ? thanks in advance, best regards, yasu From guerin@ee.upenn.edu Mon Dec 27 07:15:22 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696163A687F for ; Mon, 27 Dec 2010 07:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aijNKdmILGSC for ; Mon, 27 Dec 2010 07:15:21 -0800 (PST) Received: from talbot.seas.upenn.edu (talbotv6.seas.upenn.edu [IPv6:2001:468:1802:e064::2:0]) by core3.amsl.com (Postfix) with ESMTP id D99E83A6804 for ; Mon, 27 Dec 2010 07:15:20 -0800 (PST) Received: from [192.168.1.2] (pool-71-175-38-39.phlapa.fios.verizon.net [71.175.38.39]) (authenticated bits=0) by talbot.seas.upenn.edu (8.14.3/8.14.3) with ESMTP id oBRFHGs3021934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 27 Dec 2010 10:17:16 -0500 Message-ID: <4D18ADF9.2080001@ee.upenn.edu> Date: Mon, 27 Dec 2010 10:17:13 -0500 From: Roch Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yasuhiro Ohara References: <20101228.000931.81044378.yasu@jaist.ac.jp> In-Reply-To: <20101228.000931.81044378.yasu@jaist.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-27_07:2010-12-27, 2010-12-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Cc: ospf@ietf.org Subject: Re: [OSPF] Question about 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: , X-List-Received-Date: Mon, 27 Dec 2010 15:15:22 -0000 Once a node is added to the "labeled set" of the Dijkstra algorithm, it is never revisited. Hence, you wont be able to discover additional next hops for it. Consider a scenario where the shortest path to router C is either directly over a p2p link with a cost of 1 or through network N, also with a cost of 1. If you move router C to the labeled set first, you will never discover the path through N (the outgoing link from N to C indeed has a cost of 0). Roch On 12/27/2010 10:09 AM, Yasuhiro Ohara wrote: > Hi list. > > RFC 2328 16.1. "Calculating the shortest-path tree for an area" > (3) says that: > Note > that when there is a choice of vertices closest to the root, > network vertices must be chosen before router vertices in > order to necessarily find all equal-cost paths. > > I couldn't think of any possible case that we fail to find > all equal-cost paths when the router vertices are chosen > first. Is there any ? > > When I first felt that I understood this, I remember > that this seemed to be due to the fact that the cost is > implicitly ZERO from a network vertex to a router vertex. > But I can't think of any case now. > > Even if the network vertices are chosen later, they are added > eventually, and all the equal-cost multipaths are correctly > calculated. > > Would someone please explain ? > > thanks in advance, > best regards, > > yasu > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From yasu@jaist.ac.jp Mon Dec 27 08:17:17 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27DF3A6870 for ; Mon, 27 Dec 2010 08:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.765 X-Spam-Level: * X-Spam-Status: No, score=1.765 tagged_above=-999 required=5 tests=[AWL=1.855, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 5T5xChSSPCAi for ; Mon, 27 Dec 2010 08:17:17 -0800 (PST) Received: from mailrelayi.jaist.ac.jp (mailrelayi.jaist.ac.jp [150.65.19.7]) by core3.amsl.com (Postfix) with ESMTP id D9DEE3A681B for ; Mon, 27 Dec 2010 08:17:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,234,1291561200"; d="scan'208";a="91151626" Received: from rsd-dhcp-226.jaist.ac.jp (HELO localhost) ([150.65.47.226]) by mailrelayi.jaist.ac.jp with ESMTP; 28 Dec 2010 01:19:19 +0900 Date: Tue, 28 Dec 2010 01:19:15 +0900 (JST) Message-Id: <20101228.011915.163641456.yasu@jaist.ac.jp> To: guerin@ee.upenn.edu From: Yasuhiro Ohara In-Reply-To: <4D18ADF9.2080001@ee.upenn.edu> References: <20101228.000931.81044378.yasu@jaist.ac.jp> <4D18ADF9.2080001@ee.upenn.edu> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] Question about 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: , X-List-Received-Date: Mon, 27 Dec 2010 16:17:17 -0000 Ah, I get it. RFC 2328 requests that all mulitpaths are found when the vertex is in the candidate list. When the multipaths to a destination in the shortest path tree can be added later, then we don't need to care the order of the vertex type to install. (My implementation does this, taking another requirement that the nexthop calculation is done after the entire SPF tree is decided.) Thank you. regards, yasu From: Roch Guerin Subject: Re: [OSPF] Question about SPF Date: Mon, 27 Dec 2010 10:17:13 -0500 Message-ID: <4D18ADF9.2080001@ee.upenn.edu> > Once a node is added to the "labeled set" of the Dijkstra algorithm, it is never revisited. Hence, you wont be able to discover additional next hops for it. > Consider a scenario where the shortest path to router C is either directly over a p2p link with a cost of 1 or through network N, also with a cost of 1. If you move router C to the labeled set first, you will never discover the path through N (the outgoing link from N to C indeed has a cost of 0). > > Roch > > On 12/27/2010 10:09 AM, Yasuhiro Ohara wrote: > > Hi list. > > > > RFC 2328 16.1. "Calculating the shortest-path tree for an area" > > (3) says that: > > Note > > that when there is a choice of vertices closest to the root, > > network vertices must be chosen before router vertices in > > order to necessarily find all equal-cost paths. > > > > I couldn't think of any possible case that we fail to find > > all equal-cost paths when the router vertices are chosen > > first. Is there any ? > > > > When I first felt that I understood this, I remember > > that this seemed to be due to the fact that the cost is > > implicitly ZERO from a network vertex to a router vertex. > > But I can't think of any case now. > > > > Even if the network vertices are chosen later, they are added > > eventually, and all the equal-cost multipaths are correctly > > calculated. > > > > Would someone please explain ? > > > > thanks in advance, > > best regards, > > > > yasu > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > From p6c6d6@gmail.com Wed Dec 29 01:50:41 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB6E3A68B3 for ; Wed, 29 Dec 2010 01:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 fP-uKIy2JWEp for ; Wed, 29 Dec 2010 01:50:40 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 5E6043A689D for ; Wed, 29 Dec 2010 01:50:40 -0800 (PST) Received: by pzk5 with SMTP id 5so2920925pzk.31 for ; Wed, 29 Dec 2010 01:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=51i9MIwGDnS2O55FhMVYchMCsqy6SUmNm1/ED3XyyqU=; b=WdMQVv44s/rUy5iy8SZZMBrzQ9lsRfJKZdVoKLTIWjjyDxwhv/fk2N8qdOD8UEaYs4 kuxpjsgoiwFCPHnc67p3e7lCHiQqVRmtzcCkNRmGiA6sfvvFgoKGZ1/ZhzcBG1HQh9fD Zz72gj9fUR0VoTiOwAjKbksYLLjtwtaTfu5XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VIB+28jrXO7KiK7kyH3labwQM2GkDG4JJqoeqgPLXP+eweiTImXYAD3VWf6rvhsgFk OLRFmx4HLaaRDYuRVFCgSeK8G4CV5pgbu6113aAtHyY43U1Mo7D4YfHCx7YunBBw96Xp VYu9EpK0XR6EVDD4I+zm+ID51jtZCHGBOxk+0= MIME-Version: 1.0 Received: by 10.142.199.4 with SMTP id w4mr11793080wff.444.1293616365600; Wed, 29 Dec 2010 01:52:45 -0800 (PST) Received: by 10.142.226.12 with HTTP; Wed, 29 Dec 2010 01:52:45 -0800 (PST) Date: Wed, 29 Dec 2010 15:22:45 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32d86f2b8f804988987ef Subject: [OSPF] transit stub area X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 09:50:41 -0000 --000e0cd32d86f2b8f804988987ef Content-Type: text/plain; charset=ISO-8859-1 hi, why can't we use stub area or nssa area as transit area ? thanks --000e0cd32d86f2b8f804988987ef Content-Type: text/html; charset=ISO-8859-1 hi,

why can't we use stub area or nssa area as transit area ?

thanks

--000e0cd32d86f2b8f804988987ef-- From p6c6d6@gmail.com Wed Dec 29 02:18:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8083A68BD for ; Wed, 29 Dec 2010 02:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 CV90AlgyC9wn for ; Wed, 29 Dec 2010 02:18:35 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B6A2B3A68B0 for ; Wed, 29 Dec 2010 02:18:35 -0800 (PST) Received: by pwi7 with SMTP id 7so1501800pwi.31 for ; Wed, 29 Dec 2010 02:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=dHoX9fM3OOZcGHMprpJU5Wqp+8X4kU7T33JeUSSYbWA=; b=ItG+J+PA+71ud5pjd/ZFFTRszr9rjgFc7IbWdspTIy+Bjmf9rg3WoVTjftBgudWVRt t5oQBW9N8ZHpWpFEtCfv4QoTGNGFabPXiDxcTe3dxItBmDa7F025PWTAyJT/2RAslZcl DPVKgmXNs/ky530ihxfOBc2zpBJ06dpj1IFn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=andX4S24yWvl0Ha0VlGJbDGOujoaw06OjuG5gxL3i/rV3tSL76qhrNWKzHtEOkm5xe bMbbb8uNvZtFHaQlmhnyqQchNVQcbmXxx3/xEoBOm2C0C6VcOO/4YedeEMC6q0XrsXx6 fiB+s0pInx//RCTBtu8VrXKxyUrHhABupEm9Q= MIME-Version: 1.0 Received: by 10.142.158.19 with SMTP id g19mr11831256wfe.387.1293618041212; Wed, 29 Dec 2010 02:20:41 -0800 (PST) Received: by 10.142.226.12 with HTTP; Wed, 29 Dec 2010 02:20:41 -0800 (PST) Date: Wed, 29 Dec 2010 15:50:41 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd17f9ad250b8049889eb16 Subject: [OSPF] nssa forwarding address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 10:18:36 -0000 --000e0cd17f9ad250b8049889eb16 Content-Type: text/plain; charset=ISO-8859-1 hi, nssa rfc states that the forwarding address for a type-7 lsa is mandatory if it is to be translated to a type-5 lsa. why is this a mandatory. why not forwarding address is optional like type-5 lsas. is there any specific reason ? thanks --000e0cd17f9ad250b8049889eb16 Content-Type: text/html; charset=ISO-8859-1 hi,

nssa rfc states that the forwarding address for a
type-7 lsa is mandatory if it is to be translated to
a type-5 lsa. why is this a mandatory. why not
forwarding address is optional like type-5 lsas.
is there any specific reason ?

thanks

--000e0cd17f9ad250b8049889eb16-- From acee@lindem.com Wed Dec 29 05:41:45 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A18D28C0F8 for ; Wed, 29 Dec 2010 05:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6ujS-l35PPOB for ; Wed, 29 Dec 2010 05:41:44 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 49DB828C0DE for ; Wed, 29 Dec 2010 05:41:43 -0800 (PST) X-Authority-Analysis: v=1.1 cv=3jtQBdTzPyV+fq4oCU/u8ZPrJJGN11HvhaDVxyWhycI= c=1 sm=0 a=kj9zAlcOel0A:10 a=L1VwfK/nn2f7m25hqo7tuA==:17 a=48vgC7mUAAAA:8 a=MCtbGNCzkgsHkw6fBCUA:9 a=S5hBL8ck_5VG3PqHidMI93jnAGcA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=L1VwfK/nn2f7m25hqo7tuA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.2.37 Received: from [65.190.2.37] ([65.190.2.37:50935] helo=[192.168.1.100]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 24/AE-02631-41B3B1D4; Wed, 29 Dec 2010 13:43:49 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Wed, 29 Dec 2010 08:43:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: p6 c6d6 X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org Subject: Re: [OSPF] transit stub area X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 13:41:45 -0000 Because the interior routers (non-ABR) do not have the AS external = routes. Loops would ensue routing AS external transit traffic.=20 Hope this helps,=20 Acee =20 On Dec 29, 2010, at 4:52 AM, p6 c6d6 wrote: > hi, >=20 > why can't we use stub area or nssa area as transit area ? >=20 > thanks >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Wed Dec 29 05:44:57 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C3428C0FB for ; Wed, 29 Dec 2010 05:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHcptAoHmXf3 for ; Wed, 29 Dec 2010 05:44:56 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id 2A5CE28C0DE for ; Wed, 29 Dec 2010 05:44:56 -0800 (PST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=jWR72KE4G9sA:10 a=kj9zAlcOel0A:10 a=L1VwfK/nn2f7m25hqo7tuA==:17 a=48vgC7mUAAAA:8 a=Ozc7TXQxHBK3eABDFJcA:9 a=qvYxOyhEvdurs59Qz_UA:7 a=eaqnkXULeDTTTKUXW__PJxSvLEsA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=rzm2RhEbY081Isai:21 a=Bof0NOIzlrTI237u:21 a=L1VwfK/nn2f7m25hqo7tuA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.2.37 Received: from [65.190.2.37] ([65.190.2.37:50962] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id A0/42-19545-5DB3B1D4; Wed, 29 Dec 2010 13:47:01 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Wed, 29 Dec 2010 08:47:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: p6 c6d6 X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org Subject: Re: [OSPF] nssa forwarding address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 13:44:57 -0000 Because ASBRs within an NSSA are not advertised outside the NSSA via = ASBR summaries (type 4).=20 Hope this helps, Acee On Dec 29, 2010, at 5:20 AM, p6 c6d6 wrote: > hi, >=20 > nssa rfc states that the forwarding address for a=20 > type-7 lsa is mandatory if it is to be translated to > a type-5 lsa. why is this a mandatory. why not > forwarding address is optional like type-5 lsas. > is there any specific reason ? >=20 > thanks >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From p6c6d6@gmail.com Wed Dec 29 19:37:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B749C28C142 for ; Wed, 29 Dec 2010 19:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 ahFKaHszucnT for ; Wed, 29 Dec 2010 19:37:35 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id DCB4B28C133 for ; Wed, 29 Dec 2010 19:37:35 -0800 (PST) Received: by pzk5 with SMTP id 5so3061924pzk.31 for ; Wed, 29 Dec 2010 19:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=9kfhhwLxSsdygzVIEAVMwPiP7o2fG7yZwAQtspZuqaY=; b=Mia2k0n0DUA7cabztAyAf1ZSGsDyMHdSkmfN4MNzY6f9GJbw9Ka56uGBQD84W+Sk2Y YrsT/A9kauEunVrfz/Nfzfm9FatQyBf91S1LcqniDtL2NdU4eVIdOI7UpWsPQab+mNQn Wd2vmaOr8kj/+iyNpl/tBphiFpLkvW3RdukR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Vpa7PlntE04Qval1f2uV6xNmSMt4qXs4jmXK/p3c+qP24cPLwUi8mPGfevNRQGvdTK ZCGg3SkVy0hxUoKczGeuTS6InHDsGUjAflL3CYTNzeq3ItlCz+X0pw/d5rPZkLW0yefh qt73Z9S6d00ITKut2s/S5vorsi82Oh+8+xPlI= MIME-Version: 1.0 Received: by 10.142.72.12 with SMTP id u12mr12787671wfa.159.1293680381481; Wed, 29 Dec 2010 19:39:41 -0800 (PST) Received: by 10.142.226.12 with HTTP; Wed, 29 Dec 2010 19:39:41 -0800 (PST) Date: Thu, 30 Dec 2010 09:09:41 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001636ed69a39754c90498986fd2 Subject: [OSPF] type-2 cost plus 1 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 03:37:36 -0000 --001636ed69a39754c90498986fd2 Content-Type: text/plain; charset=ISO-8859-1 hi, In nssa rfc. == 3.2 Translating Type-7 LSAs into Type-5 LSAs If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost. == 1 is added to the type-2 cost. can anyone explain me with a topology ? thanks --001636ed69a39754c90498986fd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

In nssa rfc.

=3D=3D
3.2 Translating Type-7 LSAs into T= ype-5 LSAs


If the range's path type is 1 its metric is the h= ighest cost amongst
these LSAs; if the range's path type is 2 its me= tric is the
highest Type-2 cost + 1 amongst these LSAs.=A0 (See Section 2.5
step (5)= .)=A0 1 is added to the Type-2 cost to ensure that the
translated Type-5= LSA does not appear closer on the NSSA
border than a translatable Type-= 7 LSA whose network has the
same [address,mask] pair and Type-2 cost.
=3D=3D

1 is added to th= e type-2 cost. can anyone explain me with a topology ?

thanks


--001636ed69a39754c90498986fd2--