Hi Acee,
let me start by saying that I fully support the effort to define
extensible LSAs in OSPF. I also don't believe we need a new protocol
version for it, nor that we need to address all the legacy in the
protocol at this point.
One piece I have a problem with is the backward compatibility. I don't
think we can afford to introduce an extension to the protocol that is
not backward compatible. I know it's easier for us who "write and
maintain" the software to do it that way, but we have to look at it from
the perspective of the users who have thousands of nodes running the
current version of the protocol deployed. Using separate OSPFv3 routing
domains during transition has significant impact on the network and
brings a lot of complexity to the operational folks. I'm afraid the
complexity associated with the backward compatibility would have to be
incorporated in the protocol, not pushed to the user.
Last, but not least, we have a similar requirements in OSPFv2. I'm in
process of writing a draft which requires additional attributes to be
flooded for link and prefix in v2. So the question is not if we want to
do it for OSPFv2, but rather how do we want to do it for OSPFv2. We can
not ask people in the field to migrate from v2 to v3, just because they
want to deploy a new functionality that required few extra bytes for
link/prefix to be flooded by OSPFv2. We have two possible approaches -
define extended LSAs for v2, or take the path of the complementary LSAs,
which would be used on top of existing LSAs and used to carry extra data
for links/prefixes. I would like to get a sentiment of the OSPF IETF
community on this.
thanks,
Peter
On 3.5.2013 17:14, Acee Lindem wrote:
Hi Anton,
Thanks for introducing the draft - I had meant to do it but am chronically
pressed for time. Here is the link:
https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/
You are correct that the draft does require a deployment upgrade. A mixed
deployment will require separate OSPFv3 routing domains and multiple OSPFv3
instances at least at the boundaries. The alternative was to require both the
existing LSAs and the Extended-LSAs to be originated in mixed deployments. This
adds quite a lot of complexity and will not be scalable in many networks. It is
definitely possible but is the is the sort of backward compatibility mechanism
people who don't write or maintain routing software propose.
As far as calling it OSPFv4, I don't think we need to do this since only the
encoding of the LSAs change. We were careful not to change the LSA semantics in
the interest of rapid acceptance, implementation, and, hopefully, deployment. I
believe the OSPFv3 moniker should be reserved for a version of the protocol
with far more changes (including deprecation of virtual links ;^).
Thanks,
Acee
On May 3, 2013, at 9:01 AM, Anton Smirnov wrote:
Hi all,
I saw this draft was published a few days ago and I wanted to discuss the approach
taken by authors. In brief, this draft deeply changes OSPFv3 by totally reworking LSA
encodings but stops short of calling it a new version of OSPF protocol. Per draft routers
supporting new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not talk to
them. So from deployment point of view section of the draft describing backward
compatibility can be reduced to simply "Totally not backward compatible".
I think no one will object that OSPFv3 rigid LSA format became big obstacle
in introducing new features and even simply catching up with ISIS.
I personally fully agree that OSPFv3 has to be deeply reworked.
But in my opinion this draft is presenting OSPFv4 without calling it so -
and carries into the new version of the protocol some outdated features of
OSPFv2.
Isn't it a time to admit that OSPFv3 is failure of epic proportions? And to
admit that stance 'to introduce minimum changes into the protocol' taken when
developing OSPFv3 architecture was deeply flawed, sacrificed long-term benefits
of introducing new protocol version to short-term benefits of quick
standardization and will continue causing difficulties unless addressed (with
LSA encodings being the most obvious but not the only one)?
--
Anton
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
