Subject: [OSPF] OSPFv3 E-LSA Compatibility

From: Acee Lindem <[email-masked]>
Date: Sat, 28 Dec 2013 22:37:21 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Sun, 29 Dec 2013 12:22:02 +0100

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.

I'm afraid that keeping the compatibility support at two different 
levels is going to create a lot of confusion.

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
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Mon, 30 Dec 2013 17:27:57 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 30 Dec 2013 18:47:56 +0100

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?

> 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 a…

I see.

>     * 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 LS…

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

> .