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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
