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

Acee Lindem <> Fri, 28 June 2013 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0B9621F9D49 for <>; Fri, 28 Jun 2013 14:19:52 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QqOWOh63joT6 for <>; Fri, 28 Jun 2013 14:19:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41F2721F9D41 for <>; Fri, 28 Jun 2013 14:19:46 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-f1-51cdfdf25fe8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7C.65.13034.2FDFDC15; Fri, 28 Jun 2013 23:19:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 17:19:45 -0400
From: Acee Lindem <>
To: Peter Psenak <>, Acee Lindem <>
Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
Thread-Index: AQHOdEU2VWKceH6uu0OHrHh9bT44jw==
Date: Fri, 28 Jun 2013 21:19:45 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
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+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuO6nv2cDDdZ+1reYdms6m0XLNlaL lnv32C127G5nc2DxmPJ7I6vHkiU/mTw+LLrAGsAcxWWTkpqTWZZapG+XwJXxaOZDpoJOhYq5 M1qYGxh7pboYOTkkBEwkrp24zQRhi0lcuLeerYuRi0NI4CijxIvOu6wQznJGifOHzrGAVLEJ 6Eg8f/SPGcQWEXCW6Dh6FaiIg4NZwF3i7EsZkLCwQIjEsZlP2SFKQiWOf1wFVa4ncXTrelYQ m0VAVaJ/wjywGl4Bb4mti3sYQWxOAU2J7lPLwGoYgQ76fmoN2HHMAuISt57MhzpUQGLJnvPM ELaoxMvH/8DqRYHmtx07ww4RV5ZY8mQ/C0SvjsSC3Z/YIGxrib4rD6FmakssW/iaGeIGQYmT M5+wTGAUn4Vk3Swk7bOQtM9C0j4LSfsCRtZVjBylxalluelGBpsYgRF3TIJNdwfjnpeWhxil OViUxHlX6Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYrXlO7CH3d8Wp7/ZK8T6YI/gh WMr6eIXg+R7VCW/fVT9TbY5RuV3QcPPTn+81bxSef/Q07E7T8bBPi3e5KevV5bzurkPP9vkO Zz8+T/GVv7Wts8/+7DatpRo/w6ymnn72WeXo4gA5KdsdCdM8vpmdbtueWJCYvepv3GLLK9tf qR1ga+j+nLBLiaU4I9FQi7moOBEAqXCRFYYCAAA=
Cc: "" <>
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: Fri, 28 Jun 2013 21:19:52 -0000

Great Peter - I'll discuss with my co-authors and update before cut-off.

On 6/28/13 6:29 AM, "Peter Psenak" <> wrote:

>Hi Acee,
>On 28.6.2013 11:44, Acee Lindem wrote:
>> Hi Anton, Peter,
>> If I were to be convinced that #2 is the way to go, I like making it
>>explicit configurations and only applicable to service provider and
>>large enterprise deployments. That way, OSPFv3 implementations
>>specifically for the homenet environments could omit it.
>I'm fine with the config based approach.
>> Thanks,
>> Acee
>> On Jun 28, 2013, at 4:00 AM, Anton Smirnov wrote:
>>>    Hi Acee,
>>>    while I appreciate developer's simplicity of option 1 this approach
>>>is good only for greenfield deployment. For any existing sizable OSPFv3
>>>network its migration limitation may become an insurmountable obstacle.
>>>    My preference is combination of options: start migration as option
>>>2 and when migration is completed lock on 1.
>>>    Benefits are that migration is possible; LSDB is doubled only for
>>>period of migration; and once migration is completed there is no need
>>>to worry about dynamics of old-style router entering the domain.
>>>    Downside is relative complexity of implementation but that's the
>>>price to pay for simplicity of OSPFv3. BTW, entering and exiting
>>>migration may be manual (via configuration), so this mixed approach may
>>>be simpler to implement than 'pure' option 3.
>>>    Said all that, individual products targeting greenfield deployment
>>>scenario may skip implementation of migration. Say, homenet may require
>>>support of extended LSAs from day 1. That would mean that homenet
>>>products will not be deployable in existing old-style-LSA networks -
>>>but that probably is not the intent anyway.
>>> Anton
>>> On 06/27/2013 10: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
>>>> 87 in Berlin. Where there appears to be some amount of disagreement is
>>>> in the backward compatibility mechanisms. There are basically 3
>>>> (as well as subtle variants)
>>>>          1. The approach in the draft, only allow adjacencies between
>>>> routers supporting the extended encodings. Backward compatibility
>>>> 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
>>>> encodings at the respective flooding scope. This was the approach
>>>> 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
>>>> support the new format. The only potential problem with this approach
>>>> a dynamics when a router not supporting the extended format
>>>> 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
>>>> 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