doc/mpls/ChangeLog.opaque.txt

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