Subject: [OSPF] Stub areas and type 4 summary LSAs

From: RAMAKRISHNADTV <[email-masked]>
Date: Fri, 20 Sep 2013 07:03:45 +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***

---

From: Acee Lindem <[email-masked]>
Date: Fri, 20 Sep 2013 12:09:12 +0000

Hi Ramakrisha,
You are correct and my implementation does, in fact, generate a SeqNumberMismatch event in this case. 
Thanks,
Acee 
On Sep 20, 2013, at 3:03 AM, RAMAKRISHNADTV wrote:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf