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

Michael Barnes <> Sat, 29 June 2013 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E78F21F9B95 for <>; Fri, 28 Jun 2013 17:33:57 -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 owB1S3JJtlcn for <>; Fri, 28 Jun 2013 17:33:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9712321F9B85 for <>; Fri, 28 Jun 2013 17:33:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3786; q=dns/txt; s=iport; t=1372466023; x=1373675623; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=el0O0OIag9rIhCTWzIf3VFzeyfYl93rmUmEV3odbSBQ=; b=SeN55rsSmOmATGBuVn9lTEdob1AtVTx7tUEtHCoQd18akQaOx1RIrzL1 3wlj7p1afQRrAqRGtIpOHh/aO0ihYnB24ynPQigtHxOY4LrPTiD3g2S1X dpzaykoLj9+fm6bXCZnvW+9pGt9t8jDwnJijdK28N58YMUX0flNqotHkT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="84581600"
Received: from ([]) by with ESMTP; 29 Jun 2013 00:33:42 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id r5T0XfSn018358 for <>; Sat, 29 Jun 2013 00:33:41 GMT
Message-ID: <>
Date: Fri, 28 Jun 2013 17:33:41 -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: Sat, 29 Jun 2013 00:34:00 -0000

Hi Acee,

Here are some ideas you can consider to reduce the LSDB size and/or the 
complexity of the code.

You could require that any data advertised in an old LSA MUST also be 
advertised in a new LSA. That would reduce the complexity (since all old 
LSAs could be ignored) at the expense of LSDB size.

Alternately, you could allow a router an option of advertising the new 
LSA when it must advertise the old LSA. So in the case that the new LSA 
does not provide any additional information, and the router must 
originate the old LSA regardless, then the LSDB size is reduced without 
any loss of information, but obviously at the cost of complexity.

If it is optional for a router to advertise a new LSA as above, then it 
would be helpful, to reduce code complexity, to require that if the 
router does advertise both old and new LSAs, then a new LSA with the 
same type and LSID as the old must contain a superset of the information 
advertised in the old LSA. This way other routers can know when they can 
safely ignore the old LSA.


On 06/27/2013 01:53 PM, Acee Lindem wrote:
> Peter, Michael,
> I guess you guys have considered the complexity this adds. For example,
> you now need rules for LSDB entry selection during the SPF given that the
> calculation will now have to handle a mix of extended and non-extended
> LSAs. #2 is actually my least favorite of the three options given the
> complexity it burdens us with forever.
> Acee
> On 6/27/13 1:43 PM, "Peter Psenak" <> wrote:
>> Hi Acee,
>> my preference is option (2).
>> thanks,
>> Peter
>> On 27.6.2013 22:18, 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
> _______________________________________________
> OSPF mailing list