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

Anton Smirnov <> Tue, 07 May 2013 08:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14BF221F8FDC for <>; Tue, 7 May 2013 01:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L4-o71Jtx3ma for <>; Tue, 7 May 2013 01:44:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B413D21F8F62 for <>; Tue, 7 May 2013 01:44:12 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r478i7pN013634; Tue, 7 May 2013 10:44:07 +0200 (CEST)
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r478hfEL018292; Tue, 7 May 2013 10:43:56 +0200 (CEST)
Message-ID: <>
Date: Tue, 07 May 2013 10:43:41 +0200
From: Anton Smirnov <>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2
MIME-Version: 1.0
To: Acee Lindem <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Tue, 07 May 2013 08:44:18 -0000

    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 

    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.


On 05/04/2013 11:31 PM, Acee Lindem wrote:
> 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."