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

Acee Lindem <acee.lindem@ericsson.com> Thu, 27 June 2013 20:18 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F28DC11E80D1 for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 13:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4HCcroyF+NnI for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 13:18:05 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDD21F9EFB for <OSPF@ietf.org>; Thu, 27 Jun 2013 13:18:02 -0700 (PDT)
X-AuditID: c618062d-b7fc76d0000063be-4d-51cc9df9838d
Received: from EUSAAHC002.ericsson.se (Unknown_Domain []) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.34.25534.9FD9CC15; Thu, 27 Jun 2013 22:18:01 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([]) by EUSAAHC002.ericsson.se ([]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 16:18:01 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "OSPF@ietf.org" <OSPF@ietf.org>
Thread-Topic: OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
Thread-Index: AQHOc3NrhDx5rAEZaU6K9RwM6LdMag==
Date: Thu, 27 Jun 2013 20:18:00 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4718D71Beusaamb101ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPn+7PuWcCDS7/tbFouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXMOXmUqOKlUceXwFLYGxgcyXYycHBICJhIbN39nhbDFJC7c W8/WxcjFISRwlFHizaQjLCAJIYHljBLff6uC2GwCOhLPH/1jBrFFBJQlzt9qYe9i5OAQFvCQ mHnUDiLsK9G98zw7hK0nMfnQfUYQm0VAVaJ16gwmEJtXwFti7rQlYHsZgfZ+P7UGLM4sIC5x 68l8Joh7BCSW7DnPDGGLSrx8/A+sXhRoZtuxM+wQcWWJJU/2s0D05kss2DAbar6gxMmZT1gm MArPQjJ2FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwGKrXWuJGx252ZDULGDlWMXKUFqeW 5aYbGWxiBMbJMQk23R2Me15aHmKU5mBREuddpXcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VANj5yXvoKgO45v7psp9XFQnMmXSkuab2pfkeWU33rWK+X/U90JfstuUVaJVu7vKvtxM7Z78 TftB2+brx82uX3n+t+3UvfUHfbbM8ImvCHVNSdgcu+XFss9X1za8aZb8cyTpCvOKWzdPndx2 q3ie9nW3torAike+Rv3sbFU8gReEmeM3h2bzSBQuUGIpzkg01GIuKk4EAPsPZFhhAgAA
Subject: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 20:18:12 -0000

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.