[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