Hi Peter, On Dec 29, 2013, at 6:22 AM, Peter Psenak wrote:
> Hi Acee, > > some clarification is required in terms of EL-bit setting in various > compatibility cases. I assume EL-bit is set only in "Normal" mode. > > Regarding the AreaExtendedLSASupport, you defined only two modes for it, > MixedMode is missing, not sure why. Also, if we keep both global and per area > compatibility support, some intersection analysis between the two is required > - e.g. do we support 'MixedMode' at global level with 'Normal' at area level > - these two contradict each other in terms of adjacency formation with legacy > routers. We could support all three values at the area level as well. My intention is that the area setting would take precedence over the global level for area/link-local scoped LSAs in the area and area adjacency formation. I see what you mean about a contradiction. Let me see if I can clear it up. AreaExtendedLSASupport * Global - Support for Extended LSAs is controlled by the value of ExtendedLSASupport. * Normal - Extended LSAs will be originated for Area and Link-local scoped LSAs within the area. Adjacencies are not formed with Routers not supporting the Extended LSAs. The handling of AS External LSA is controlled by the value of ExtendedLSASupport. * MixedMode - Both extended and non-extended LSAs will be originated for Area and Link-local scoped LSAs within the area. Adjacencies are not formed with Routers not supporting the Extended LSAs. The handling of AS External LSA is controlled by the value of ExtendedLSASupport. > > I'm afraid that keeping the compatibility support at two different levels is > going to create a lot of confusion. I don't want to add more confusion. I was merely looking for a way to migrate one area at a time to the extended LSA format. Thanks, Acee > > thanks, > Peter > > > On 12/28/13 23:37 , Acee Lindem wrote: >> Given that the authors really don't want to leave a legacy of complexity >> with the backward compatibility cases. I think we are going to reduce >> the compatibility cases to: >> >> ExtendedLSASupport >> This is an enumeration type indicating the extent to which the >> OSPFv3 instance supports the TLV format described herein for >> Extended LSAs. The valid value for the enumeration are: >> >> * None - Non-extended LSAs will not be originated or used in the >> SPF calculation. >> >> * Normal - Extended LSAs will be originated and adjacencies will >> not be formed with OSPFv3 routers not supporting this >> specification. >> >> * MixedMode - Both extended and non-extended LSAs will be >> originated. OSPFv3 adjacencies will be formed with OSPFv3 >> routers not supporting this specification. The non-extended >> LSAs are used for the SPF computation. >> >> >> One thing that occurred to me is that it might be useful to migrate a single >> area. In this case, one would allow the following modes: >> >> AreaExtendedLSASupport >> This is an enumeration type indicating the extent to which the >> OSPFv3 area supports the TLV format described herein for >> Extended LSAs. The valid value for the enumeration are: >> >> * None - Non-extended LSAs will not be originated or used in the >> SPF calculation. >> >> * Normal – Area and link-local scoped Extended LSAs will be originated >> and adjacencies will not be formed with OSPFv3 routers in the area not >> supporting this Extended LSAs. AS scoped LSAs will be originated as >> non-extended LSAs. >> >> >> Thoughts? >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
