[OSPF] Some questions on RFC3101
guoqiang 03022 <guoqiang@h3c.com> Thu, 24 July 2008 00:50 UTC
Return-Path: <ospf-bounces@ietf.org>
X-Original-To: ospf-archive@optimus.ietf.org
Delivered-To: ietfarch-ospf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70763A6868; Wed, 23 Jul 2008 17:50:48 -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 8F4A93A6868 for <ospf@core3.amsl.com>; Wed, 23 Jul 2008 17:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.327
X-Spam-Level: **
X-Spam-Status: No, score=2.327 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1, RELAY_IS_221=2.222]
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 NDFFgYoARpar for <ospf@core3.amsl.com>; Wed, 23 Jul 2008 17:50:46 -0700 (PDT)
Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 448B43A6857 for <ospf@ietf.org>; Wed, 23 Jul 2008 17:50:44 -0700 (PDT)
Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K4H00MJGJQ1YZ@h3cml01-in.huawei-3com.com> for ospf@ietf.org; Thu, 24 Jul 2008 08:51:37 +0800 (CST)
Received: from huawei-3com.com ([172.25.15.132]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K4H00CDWJQ1QD@h3cml01-in.huawei-3com.com> for ospf@ietf.org; Thu, 24 Jul 2008 08:51:37 +0800 (CST)
Received: from [172.25.15.129] (Forwarded-For: [222.129.48.22]) by h3cmc01-in.huawei-3com.com (mshttpd); Thu, 24 Jul 2008 08:52:56 +0800
Date: Thu, 24 Jul 2008 08:52:56 +0800
From: guoqiang 03022 <guoqiang@h3c.com>
To: ospf@ietf.org
Message-id: <40a2a3c3bd.3c3bd40a2a@huawei-3com.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-language: zh-CN
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
Subject: [OSPF] Some questions on RFC3101
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ospf-bounces@ietf.org
Errors-To: ospf-bounces@ietf.org
Hi,
I have some questions on RFC3101,NSSA.
(1) As per RFC2328, under section 12.4.4.1:
RTA and RTB would originate the same set of
AS-external-LSAs. These LSAs, if they specify
the same metric, would be functionally
equivalent since they would specify the same
destination and forwarding address (RTX).
This leads to a clear duplication of
effort. If only one of RTA or RTB originated
the set of AS-external-LSAs, the routing would
remain the same, and the size of the link state
database would decrease. However, it must be
unambiguously defined as to which router
originates the LSAs (otherwise neither may,
or the identity of the originator may
oscillate). The following rule is thereby
established: if two routers, both reachable
from one another, originate functionally
equivalent AS-external-LSAs (i.e., same
destination, cost and non-zero forwarding
address), then the LSA originated by the router
having the highest OSPF Router ID is used.
The router having the lower OSPF Router ID can
then flush its LSA.
Does the translated Type-5 LSAs act the same as above? if so, how can two abrs do the translation together without aggregation?
(2) In rfc1587, the Type-7 to Type-5 translation is done according to routes generated by type-7 LSAs, while in rfc3101, the translation is based on Type-7 LSAs.
Why this change hanppens? if the abr has a type-7 lsa with P-bit set, but hasn't a type-7 route(maybe inter or none),shall the Type-7 LSA be translated?
(3) In Section 2.4 "Originating Type-7 LSAs" and 2.5
"Calculating Type-7 AS External Routes", when two
lsa functions the same, the Type-7 LSA with the
P-bit set is preferred. while in rfc1587, the
Type-5 LSA is prefferred.
Is it because to choose the more widely spread LSA to avoid Appendix E situation? What's the reason?
Thanks and Regards
-guoqiang
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] Some questions on RFC3101 guoqiang 03022
- Re: [OSPF] Some questions on RFC3101 Acee Lindem