1
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
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.
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.
19
2. Feature enhancements
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.
25
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
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".
34
1.2 In "free_opaque_info_per_id()", there was a crucial typo which
35
ignores a condition test.
37
"if (oipi->lsa != NULL);" <-- semicolon!
39
2. Feature enhancements
43
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
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.
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
56
1.3 URL for the opaque-type assignment reference has changed.
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.
62
1.5 One of attached documentation "opaque_lsa.txt" has changed to
63
reflect the latest coding.
65
2. Feature enhancements
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.
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.
80
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
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.
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...
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.
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.
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)".
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.
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)()"
132
2. Feature enhancements
134
2.1 The global bitmap "opaque" has introduced instead of former flag
135
"OpaqueCapable", to store complex conditions to handle Opaque-LSAs.
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.
140
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
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.
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.
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.
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.
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...
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.
183
1.5 Some typo have fixed.
187
opaque_lsa_originate_callback (list funclist, void *lsa_type_dependent)
191
2. Feature enhancements
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.
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.
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.
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.
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.
218
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
221
Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.
added
removed
ospfd/ChangeLog.opaque.txt
