Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt

Michael Barnes <> Thu, 27 June 2013 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D603521F9DFD for <>; Thu, 27 Jun 2013 13:28:56 -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 Qr4cpSAW44Yi for <>; Thu, 27 Jun 2013 13:28:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D928121F9F61 for <>; Thu, 27 Jun 2013 13:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2801; q=dns/txt; s=iport; t=1372364915; x=1373574515; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9xi4U6EbHIt/VGZqfRHtEXfvtTYYIxnzqvtCzWekOdU=; b=foN8CAkQk9A/PCStjjkEPM17oTMg+jDoXInugchn70eGK1doATMqqzk6 Ia2VGw/K0CGmGeD2nT7fMdA/oeERKKhpGqQs9qI5ULtYe41urcz+W/WIk 7d4jKWGW66wqFI5zTfJcaNRkeyNnZ+1/nZeQWGSNDlNQkPg/ndMB4WIDR s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIFAOSfzFGrRDoI/2dsb2JhbABbgwkxAb9UgQIWdIIjAQEBAQMBAQE1NgoRCxgJFg8JAwIBAgEVMBMGAgEBiAkNuzkEj1wWg08DiSKOI4YhiySDMRw
X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="81954574"
Received: from ([]) by with ESMTP; 27 Jun 2013 20:28:30 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id r5RKSTrS014458 for <>; Thu, 27 Jun 2013 20:28:29 GMT
Message-ID: <>
Date: Thu, 27 Jun 2013 13:28:28 -0700
From: Michael Barnes <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
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: Thu, 27 Jun 2013 20:28:57 -0000

My preference would be for Option 2. This will allow the new LSAs to be 
used for enhancements that we have not yet envisioned. Regarding the 
doubling of the LSDB size, I would say that there should be 
configuration options on whether the new LSAs should be used so that an 
operator can control this. It would allow an operator to keep the new 
LSAs from being originated until all of the routers can originate them. 
On the other hand, another operator might have a need for new LSAs 
before the area fully supports them and choose to live with the 
increased LSDB size. IMHO that flexibility is very desirable.

I would also say that the U bit should be set. This would allow, for 
example, the External LSA to be enhanced to carry some information that 
would only be of interest to another ASBR or an ABR, and it wouldn't 
matter if other routers understood it.


On 06/27/2013 01:18 PM, Acee Lindem wrote:
> 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