Annotation of embedaddon/quagga/doc/mpls/ChangeLog.opaque.txt, revision 1.1.1.1
1.1 misho 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.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to ChangeLog.opaque.txt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc / mpls