ospfd/ChangeLog.opaque.txt

   1 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
   2 Changes 2002.12.20
   3
   4 1. Bug fixes
   5
   6   1.1 When an opaque LSA is being removed from (or added to) the LSDB,
   7       it does not mean a change in network topology. Therefore, SPF
   8       recalculation should not be triggered in that case.
   9       There was an assertion failure problem "assert (rn && rn->info)"
  10       inside the function "ospf_ase_incremental_update()", because
  11       the upper function "ospf_lsa_maxage_walker_remover()" called it
  12       when a type-11 opaque LSA is removed due to MaxAge.
  13
  14   1.2 Type-9 LSA is defined to have "link-local" flooding scope.
  15       In the Database exchange procedure with a new neighbor, a type-9
  16       LSA was added in the database summary of a DD message, even if
  17       the link is different from the one that have bound to.
  18
  19 2. Feature enhancements
  20
  21   2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether
  22       has introduced about a year ago, it was only a symbol definition
  23       and actual handling mechanism was not implemented. Now it works.
  24
  25 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
  26 Changes 2002.7.8
  27
  28 1. Bug fixes
  29
  30   1.1 When "ospf_delete_opaque_functab()" is called, internal structure
  31       "oipt" remain unfreed. If register/delete functab is repeated,
  32       illegal memory access happens due to this "oipt".
  33
  34   1.2 In "free_opaque_info_per_id()", there was a crucial typo which
  35       ignores a condition test.
  36
  37       "if (oipi->lsa != NULL);" <-- semicolon!
  38
  39 2. Feature enhancements
  40
  41   None.
  42
  43 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
  44 Changes 2001.12.03
  45
  46 1. Bug fixes
  47
  48   1.1 Though a new member "oi" has added to "struct ospf_lsa" to control
  49       flooding scope of type-9 Opaque-LSAs, the value was always NULL
  50       because no one set it.
  51
  52   1.2 In the function "show_ip_ospf_database_summary()" and "show_lsa_
  53       detail_adv_router()", VTY output for type-11 Opaque-LSAs did not
  54       work properly.
  55
  56   1.3 URL for the opaque-type assignment reference has changed.
  57
  58   1.4 In the file "ospf_mpls_te.c", printf formats have changed to
  59       avoid compiler warning messages; "%lu" -> "%u", "%lx" -> "%x".
  60       Note that this hack depends on OS, compiler and their versions.
  61
  62   1.5 One of attached documentation "opaque_lsa.txt" has changed to
  63       reflect the latest coding.
  64
  65 2. Feature enhancements
  66
  67   2.1 Knowing that it is an ugly hack, an "officially unallocated"
  68       opaque-type value 0 has newly introduced as a "wildcard",
  69       which matches to all opaque-type.
  70       This value must not be flooded to the network, of course.
  71
  72   2.2 The Opaque-core module makes use of newly introduced hooks to
  73       dispatch every LSDB change (LSA installation and deletion) to
  74       preregistered opaque users.
  75       Therefore, by providing appropriate callback functions as new
  76       parameters of "ospf_register_opaque_functab()", an opaque user
  77       can refer to every LSA instance to be installed into, or to be
  78       deleted from, the LSDB.
  79
  80 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
  81 Changes 2001.10.31
  82
  83 1. Bug fixes
  84
  85   1.1 Since each LSA has their own lifetime, they will remain in a
  86       routing domain (being stored in LSDB of each router), until their
  87       age naturally reach to MaxAge or explicitly being flushed by the
  88       originated router. Therefore, if a router restarted with a short
  89       downtime, it is possible that previously flooded self-originated
  90       LSAs might received if the NSM status is not less than Exchange.
  91
  92       There were some problems in the way of handling self-originated
  93       Opaque-LSAs if they are contained in a received LSUpd message,
  94       but not installed to the local LSDB yet.
  95       Regardless of some conditions to start originating Opaque-LSAs
  96       (there should be at least one opaque-capable full-state neighbor),
  97       the function "ospf_flood()" will be called to flood and install
  98       this brand-new looking LSA.
  99       As the result, when the NSM of an opaque-capable neighbor gets
 100       full, internal state inconsistency happens; a user of Opaque-LSA
 101       such as MPLS-TE can refer to self-originated LSAs in the local
 102       LSDB, but cannot modify their contents...
 103
 104       Above problems have fixed with a policy "flush it from the whole
 105       routing domain and keep silent until the flushing completed".
 106       By using this sweeping technique, we can be free from confusion
 107       caused by self-originated LSAs received via network.
 108
 109   1.2 The function "ospf_opaque_type_name()" contained massive ifdefs
 110       corresponding to each "opaque-type".
 111       These unnecessary ifdefs are removed completely.
 112
 113   1.3 In the function "ospf_delete_opaque_functab()", there was an
 114       improper loop control that causes illegal memory access.
 115       Original coding was "next = nextnode (node)".
 116
 117   1.4 The function "ospf_mpls_te_ism_change()" could not handle the
 118       case when the ISM changes from Waiting to DR/BDR/Other.
 119       So, there was a case that even if one of an ISM become
 120       operational and MPLS-TE module has started, the corresponding
 121       Opaque-LSA cannot be originated.
 122
 123   1.5 The function "ospf_opaque_lsa_reoriginate_schedule()" did not
 124       allow to be called multiple times, simply because handling
 125       module for the given "lsa-type & opaque-type" already exists.
 126       But this assumption seems to be wrong.
 127       Change the policy to allow this function to be called multiple
 128       times and let the caller to decide what should do when the
 129       corresponding callback function "(* functab->lsa_originator)()"
 130       is called.
 131
 132 2. Feature enhancements
 133
 134   2.1 The global bitmap "opaque" has introduced instead of former flag
 135       "OpaqueCapable", to store complex conditions to handle Opaque-LSAs.
 136
 137   2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic
 138       -06.txt", no significant changes with 05 version, though.
 139
 140 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
 141 Changes 2001.08.03
 142
 143 1. Bug fixes
 144
 145   1.1 Even if the ospfd started with opaque capability enabled, when
 146       the ospfd receives an unknown opaque-type (unregistered by the
 147       function "ospf_register_opaque_functab()" beforehand), the LSA
 148       was discarded. As the result, only the opaque-LSAs that have
 149       commonly registered by opaque-capable ospf routers can be
 150       flooded in a routing domain.
 151
 152       This behavior has fixed so that arbitrary opaque-type LSAs can
 153       be flooded among opaque-capable ospf routers.
 154       If the ospfd has opaque-LSA capability but disabled at runtime,
 155       received opaque-LSAs can be accepted and registered to LSDB as
 156       is, but not be flooded to the network; those opaque LSAs will
 157       remain in LSDB until explicitly flushed by incoming LSUpd
 158       messages with MaxAge, or their age naturally reaches to MaxAge.
 159
 160   1.2 The function "ospf_register_opaque_functab()" did not check
 161       if the entry corresponding to the given "lsa-type, opaque-type"
 162       combination already exists or not.
 163       This problem has fixed not to allow multiple registration.
 164
 165   1.3 Since type-11 (AS external) LSAs will be flooded beyond areas,
 166       there is little relationship between "struct lsa" and "struct
 167       area". More specifically, the pointer address "lsa->area" can
 168       be NULL if the lsa-type is 11, thus an illegal memory access
 169       will happen. This problem has fixed.
 170
 171   1.4 When self-originated opaque-LSAs are received via network and
 172       if the corresponding opaque-type functions are not available
 173       (they have already deleted) at that time, those LSAs were
 174       dropped due to "unknown opaque-type" error.
 175       After the problem 1.1 has fixed, those "self-originated" LSAs
 176       were registered to LSDB and then flooded to the network, even
 177       if the processing functions did not exist...
 178
 179       After all, this problem has fixed so that those LSAs should
 180       explicitly be flushed from the routing domain immediately, if
 181       the processing functions cannot find at that time.
 182
 183   1.5 Some typo have fixed.
 184
 185       --- EXAMPLE ---
 186       static int
 187       opaque_lsa_originate_callback (list funclist, void *lsa_type_dependent)
 188                                                           ^^^^^
 189       --- EXAMPLE ---
 190
 191 2. Feature enhancements
 192
 193   2.1 According to the description of rfc2328 in section 10.8, any
 194       change in the router's optional capabilities should trigger
 195       the option re-negotiation procedures with neighbors.
 196
 197       --- EXCERPT ---
 198                               If for some reason the router's optional
 199         capabilities change, the Database Exchange procedure should be
 200         restarted by reverting to neighbor state ExStart.
 201       --- EXCERPT ---
 202
 203       For the opaque-capability changes, this feature has implemented.
 204       More specifically, if "ospf opaque-lsa" or "no ospf opaque-lsa"
 205       VTY command is given at runtime, all self-originated LSAs will
 206       be flushed immediately and then all neighbor status will be
 207       forced to ExStart by generating SeqNumberMismatch events.
 208
 209   2.1 When we change opaque-capability dynamically (ON -> OFF -> ON),
 210       there was no trigger at "OFF->ON" timing to reactivate opaque
 211       LSA handling modules (such as MPLS-TE) that have once forcibly
 212       stopped at "ON->OFF" timing.
 213       Now this dynamic reactivation feature has added.
 214
 215   2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic
 216       -05.txt", no significant changes with 04 version, though.
 217
 218 ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
 219 Changes 2001.03.28
 220
 221   Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.