Date: Fri, 20 Dec 2002 17:28:45 +0900
From: Masahiko Endo <endo@suri.co.jp>
Reply-To: zebra@zebra.org
To: zebra@zebra.org
Cc: kunihiro@zebra.org, yokota@kddlabs.co.jp
Subject: [zebra 16823] [PATCH] Bugfix and new feature in Opaque-LSA
handling.

----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
Changes 2002.12.20

1. Bug fixes

  1.1 When an opaque LSA is being removed from (or added to) the LSDB,
      it does not mean a change in network topology. Therefore, SPF
      recalculation should not be triggered in that case.
      There was an assertion failure problem "assert (rn && rn->info)"
      inside the function "ospf_ase_incremental_update()", because
      the upper function "ospf_lsa_maxage_walker_remover()" called it
      when a type-11 opaque LSA is removed due to MaxAge.

  1.2 Type-9 LSA is defined to have "link-local" flooding scope.
      In the Database exchange procedure with a new neighbor, a type-9
      LSA was added in the database summary of a DD message, even if
      the link is different from the one that have bound to.

2. Feature enhancements

  2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether
      has introduced about a year ago, it was only a symbol definition
      and actual handling mechanism was not implemented. Now it works.
diff --git a/ospfd/ospf_lsa.c b/ospfd/ospf_lsa.c
index c2fade2..9a9942f 100644
--- a/ospfd/ospf_lsa.c
+++ b/ospfd/ospf_lsa.c
@@ -2377,6 +2377,11 @@
       break;
 #ifdef HAVE_OPAQUE_LSA
     case OSPF_OPAQUE_LINK_LSA:
+      if (IS_LSA_SELF (lsa))
+          lsa->oi = oi; /* Specify outgoing ospf-interface for this LSA. */
+      else
+          ; /* Incoming "oi" for this LSA has set at LSUpd reception. */
+      /* Fallthrough */
     case OSPF_OPAQUE_AREA_LSA:
     case OSPF_OPAQUE_AS_LSA:
       new = ospf_opaque_lsa_install (lsa, rt_recalc);
@@ -2611,21 +2616,32 @@
 
         switch (lsa->data->type)
           {
-          case OSPF_AS_EXTERNAL_LSA:
 #ifdef HAVE_OPAQUE_LSA
           case OSPF_OPAQUE_AS_LSA:
+          case OSPF_OPAQUE_LINK_LSA:
+          case OSPF_OPAQUE_AREA_LSA:
+            /*
+             * As a general rule, whenever network topology has changed
+             * (due to an LSA removal in this case), routing recalculation
+             * should be triggered. However, this is not true for opaque
+             * LSAs. Even if an opaque LSA instance is going to be removed
+             * from the routing domain, it does not mean a change in network
+             * topology, and thus, routing recalculation is not needed here.
+             */
+            break;
 #endif /* HAVE_OPAQUE_LSA */
 #ifdef HAVE_NSSA
-	  case OSPF_AS_NSSA_LSA:
+	      case OSPF_AS_NSSA_LSA:
 #endif
-	    ospf_ase_incremental_update (lsa, ospf_top);
-            break;
+          case OSPF_AS_EXTERNAL_LSA:
+	       ospf_ase_incremental_update (lsa, ospf_top);
+           break;
           default:
-	    ospf_spf_calculate_schedule ();
-            break;
+	       ospf_spf_calculate_schedule ();
+           break;
           }
 
-	ospf_lsa_maxage (lsa);
+	   ospf_lsa_maxage (lsa);
       }
 
   return 0;