1----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
2Changes 2001.12.03
3
41. 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
232. 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----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
39Changes 2001.10.31
40
411. 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
902. 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----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
99Changes 2001.08.03
100
1011. 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
1492. 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----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
177Changes 2001.03.28
178
179  Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.
180