Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt

Hi Acee,

my preference is option (2).

thanks,
Peter

On 27.6.2013 22:18, Acee Lindem wrote:
> I don't think there is much disagreement that we need a direct way to
> extend the base OSPFv3 LSAs and I will be presenting this draft at IETF
> 87 in Berlin. Where there appears to be some amount of disagreement is
> in the backward compatibility mechanisms. There are basically 3 options
> (as well as subtle variants)
>
>
>          1. The approach in the draft, only allow adjacencies between
> routers supporting the extended encodings. Backward compatibility would
> have to be provided with separate instances and topology.
>
>         2. Both the current and extended versions of the LSAs are
> originated as long as there are routers not supporting the new extended
> encodings at the respective flooding scope. This was the approach taken
> in "Multi-toplogy routing in OSPFv3 (MT-OSPFV3)",
> draft-ietf-ospf-mt-ospfv3-04.txt. However, it has the undesirable
> property of roughly doubling the size of the LSDB.
>
>        3. Switch to the extended format only after all the routers at
> the flooding scope support it. Use OSPF demand circuit-like (RFC 1793)
> signaling to determine whether or not all routers in the flooding scope
> support the new format. The only potential problem with this approach is
> a dynamics when a router not supporting the extended format successively
> leaves and enters the routing domain.
>
> What is the WG preference? I'm still in favor of the approach in the
> draft (#1) given the simplicity and stability properties. What we'd lose
> in slowed deployment would be more than made up standardization and
> availability. Also, it would satisfy the homenet requirements we
> desperately need to satisfy.
>
> Thanks,
> Acee
>
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>