Subject: [OSPF] draft-acee-ospfv3-lsa-extend-00

From: Anton Smirnov <[email-masked]>
Date: Fri, 03 May 2013 15:01:55 +0200

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 3 May 2013 15:14:53 +0000

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

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 03 May 2013 17:53:49 +0200

Hi Acee,

 > As far as calling it OSPFv4, I don't think we need to do this since
 > only the encoding of the LSAs change.

Yes I understand the reasoning but that is exactly where I have a 
problem with this approach.
As it is said - “For every problem there is a solution which is simple, 
fast and wrong.”
I believe approach taken while architecturing OSPFv3 was exactly that - 
simple, fast and wrong. Exactly the reason why we have to talk right now 
about creating non-backward-compatible change is because OSPFv3 
inherited from OSPFv2 rigid LSA structure in the name of simplicity.

I just want to make sure we will not repeat the same mistake again - 
create non-backward-compatible revision of the protocol which missed 
opportunity to implement anything but only single change.

So understand me right - I fully agree with you that OSPFv3 is not 
extendable, I have no big problem with semantics of proposed extended 
LSAs, I am even ready to accept non-backward-compatible change (just 
because I do not see any other exit from dead end we cornered ourselves 
into).
But I have big problem with approach "lets do minimum changes possible". 
Solution - since it is non-backward-compatible - must first of all be 
RIGHT and only then, if possible, simple.

So what I am advocating is - lets acknowledge protocol needs major 
non-backward-compatible uplift and see what else can be fit into such 
protocol upgrade. Yes, it is going to be slow - but then result will be 
better.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Sat, 4 May 2013 21:31:52 +0000

Hi Anton, 
If you look at the drafts Fred recently refreshed, I think you'll have to
agree that we have a burning requirement for this extension. Additionally,
history has proven that more focused work has a better chance of reaching
fruition. As for backward compatibly, it is possible to do something akin
to RFC 1793 and the original unpublished version of this draft contained
these mechanisms. However, it is not clear that the complexity justifies
the mechanisms - we'll leave that for the WG to decide.
Acee 
P.S. To quote a philosopher of the late 20th century, "You can't always
get what you want. But if you try sometimes well you might find you get
what you need." 

On 5/3/13 8:53 AM, "Anton Smirnov" <[email-masked]> wrote:

>As it is said - ³For every problem there is a solution which is simple,
>fast and wrong.²
>> Thanks for introducing the draft - I had meant to do it but am
>>chronically pressed for time. Here is the link:
>>
>> 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.
>>
>>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
>>
>>>    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
>>>

---

From: Peter Psenak <[email-masked]>
Date: Sun, 05 May 2013 10:47:44 +0200

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

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 07 May 2013 10:43:41 +0200

Hi Acee,
    introducing non-backward-compatible revision of protocol is very big 
deal both for vendors and customers.
    What I am vigorously objecting is approach of developing 
non-backward-compatible protocol revision with "minimum of changes" 
being the primary requirement. This almost guarantees end result to be 
inefficient.

    Protocol *extension* must be designed to be backward compatible even 
if that makes it very complex.
    That complexity should be addressed by major protocol *revision*. 
Work on major protocol revision should start from writing requirements 
document - and this stage alone should probably last couple of years.

 > Additionally,
 > history has proven that more focused work has a better chance of
 > reaching fruition.

That's why burning need for new feature should not be mentioned while 
discussing non-backward-compatible protocol extension. Latter should be 
developed on its own.

Anton