Annotation of embedaddon/quagga/ospfd/ChangeLog.opaque.txt, revision 1.1

1.1     ! misho       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.

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>