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

Acee Lindem <> Fri, 03 May 2013 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 233F521F8B65 for <>; Fri, 3 May 2013 09:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ulvk9kku-nCE for <>; Fri, 3 May 2013 09:14:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E4A821F962D for <>; Fri, 3 May 2013 08:14:55 -0700 (PDT)
X-AuditID: c618062d-b7ff46d000006709-8c-5183d46e2f85
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5F.C1.26377.E64D3815; Fri, 3 May 2013 17:14:54 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 3 May 2013 11:14:54 -0400
From: Acee Lindem <>
To: Anton Smirnov <>
Thread-Topic: [OSPF] draft-acee-ospfv3-lsa-extend-00
Thread-Index: AQHOR/50spTN+784ukmlvZM1IxEyWpjz1PuA
Date: Fri, 03 May 2013 15:14:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgm7eleZAg8W7zC1atrFatNy7x+7A 5DHl90ZWjyVLfjIFMEVx2yQllpQFZ6bn6dslcGe8u9vPWvBItKJtxR2WBsZzgl2MnBwSAiYS 91r3sEPYYhIX7q1n62Lk4hASOMoo8WzmbUYIZxmjxL6WXhaQKjYBHYnnj/4xg9giAmoSm+9+ YgWxmQWUJR53rWYDsYUFjCXuP1jDBlFjIvGu8SE7hG0k8XHqbzCbRUBFYs6T3WA2r4C3xPMz 3YwgtpCAhsS1k6fB4pwCmhL3p+5hArEZga77fmoNE8QucYlbT+YzQVwtILFkz3lmCFtU4uXj f6wQtrLEkif7WSDqdSQW7P7EBmFbSyydPoUZwtaWWLbwNTPEDYISJ2c+YZnAKD4LyYpZSNpn IWmfhaR9FpL2BYysqxg5SotTy3LTjQw2MQLj6pgEm+4Oxj0vLQ8xSnOwKInzRnE1BgoJpCeW pGanphakFsUXleakFh9iZOLgBBFcUg2MO8s0PuesKXpmkfw/e2ehbeo/fw3u5f2r16Td29jf br8m/rDU6gDldcbPLeqlWRPfBllKSLieOPdir+jle8K2zplH9FcuKfoUkazZpnLfOPDY5Dtv NZtF75UtOBsu+ubl5h7Ju1ycs+NFYi9Uv7/0seSDwNetjnx3llddPDP51Q/xbPm10fMWKrEU ZyQaajEXFScCAOwv4vN+AgAA
Cc: "" <>
Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 May 2013 16:14:20 -0000

Hi Anton, 
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. 

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 ;^). 


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