[OSPF] Stub areas and type 4 summary LSAs

RAMAKRISHNADTV <RAMAKRISHNADTV@infosys.com> Fri, 20 September 2013 07:03 UTC

Return-Path: <RAMAKRISHNADTV@infosys.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2721F84DB for <ospf@ietfa.amsl.com>; Fri, 20 Sep 2013 00:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level:
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isiE8XHqXYDJ for <ospf@ietfa.amsl.com>; Fri, 20 Sep 2013 00:03:54 -0700 (PDT)
Received: from KECGATE08.infosys.com (kecgate08.infosys.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9163021F8447 for <ospf@ietf.org>; Fri, 20 Sep 2013 00:03:53 -0700 (PDT)
X-TM-IMSS-Message-ID: <6721c729000f837f@infosys.com>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 6721c729000f837f ; Fri, 20 Sep 2013 12:42:21 +0530
Received: from BLRKECHUB08.ad.infosys.com (10.66.236.138) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Sep 2013 12:33:46 +0530
Received: from BLRKECMBX22.ad.infosys.com ([fe80::f035:6246:a69c:67fc]) by BLRKECHUB08.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 12:33:45 +0530
From: RAMAKRISHNADTV <RAMAKRISHNADTV@infosys.com>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Stub areas and type 4 summary LSAs
Thread-Index: AQHOtc9NvgaxpxDB2EG3xZqdC9whwA==
Date: Fri, 20 Sep 2013 07:03:45 +0000
Message-ID: <F2B120E98374B2448745C1117BDA1854444C0C09@BLRKECMBX22.ad.infosys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OSPF] Stub areas and type 4 summary LSAs
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Fri, 20 Sep 2013 07:03:59 -0000

Hi,

Could you please clarify the following point in OSPFv2 (RFC 2328) w.r.t
stub areas?

The following is excerpted from Section 10.6 (Receiving Database Description
Packets):

        When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.  Otherwise, the router looks up the
        LSA in its database to see whether it also has an instance of
        ...

This is correctly saying that stub areas should not process external
LSAs (LS type 5). But what about type 4 summary LSAs (related to ASBR)?
As far as I understand, stub areas should not receive these LSAs.
But this paragraph is not explicit about it. I believe this paragraph
needs to be updated to indicate that received type 4 summary LSAs and
type 5 external LSAs should elicit the same behavior in stub areas:
generate the neighbor event SeqNumberMismatch and stop processing the
packet.

On the other hand, originating LSA side description in RFC correctly
states as follows.

>From Section 12.4.3 (Summary-LSAs):

                ...If so, a Type 4 summary-LSA is originated for the
                destination, with Link State ID equal to the AS boundary
                router's Router ID and metric equal to the routing table
                entry's cost. Note: these LSAs should not be generated
                if Area A has been configured as a stub area....

Regards,
Ramakrishna DTV.


**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***