Hi Acee,
On 12/30/13 18:27 , Acee Lindem wrote:
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.
can you please clarify the EL-bit setting in various compatibility modes?
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.
I see.
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.
should not MixeMode above allow adjacency to be formed with routers not
supporting the Extended LSAs? MixedMode at global level allows that,
which is what we want.
thanks,
Peter
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
