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

Acee Lindem <> Fri, 28 June 2013 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C0E921F9928 for <>; Fri, 28 Jun 2013 05:44:01 -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=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1+VinmvVdosH for <>; Fri, 28 Jun 2013 05:43:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE9CD21F9CA0 for <>; Fri, 28 Jun 2013 05:41:25 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-25-51cd8473520e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2E.F5.31362.3748DC15; Fri, 28 Jun 2013 14:41:23 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 08:41:23 -0400
From: Acee Lindem <>
To: Anton Smirnov <>
Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
Thread-Index: AQHOc9WjVWKceH6uu0OHrHh9bT44j5lLI4mAgAAHpYCAACnKgA==
Date: Fri, 28 Jun 2013 12:41:22 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPn25xy9lAg5Z11hbTbk1ns2jZxmrR cu8eu8WO3e1sDiweU35vZPVYsuQnk8eHRRdYA5ijuGxSUnMyy1KL9O0SuDJm9rxmKejTqnja cp2pgbFFqYuRk0NCwETi1bxrrBC2mMSFe+vZuhi5OIQEjjJKXGv+DeUsZ5ToWN7ACFLFJqAj 8fzRP2YQW0RATWLz3U9A3RwczAJpEh9O1YKEhQVCJI7NfMoOURIqcfzjKqhyJ4lzm5rYQGwW AVWJS8degC3mFfCWuNeylwVi115GiUezTjKBJDgFNCVaTh0Fa2YEuu77qTVgcWYBcYlbT+Yz QVwtILFkz3lmCFtU4uXjf1DfKEssebKfBaJeR2LB7k9sELa1xOGP3ewQtrbEsoWvmSGOEJQ4 OfMJywRG8VlIVsxC0j4LSfssJO2zkLQvYGRdxchRWpxalptuZLiJERhzxyTYHHcwLvhkeYhR moNFSZx3g96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M8550vwtyT+zM8TJ6J71y8Tnp zZ9fJ/bNZU/cNNuxLX+C+Iqe6/lqLAUdPReCzko9v3bh3t9txYXX3yc4FayfqxsjZqia4qw0 441YaRz/N/V7UUmcf1pfRwk41yT6vN92+phTwMHtqwrdV715pHL62U/7gIedphcyRc8VuJdz +mduL+Qp3vBXiaU4I9FQi7moOBEAzqS7CYcCAAA=
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 12:44:01 -0000

Hi Anton,

On Jun 28, 2013, at 6:11 AM, Anton Smirnov wrote:

>   Hi Acee, Peter,
>   IMO pure option 2 has its own problems. It is easy to imagine some future feature requiring all routers in the area understanding information the feature is sending in extended LSA. So if backward compatibility is preserved indefinitely then there is a risk of old-style-LSA router joining the domain and breaking the feature.

Supporting the extended LSAs doesn't imply that the implementation will support all the attendant TLVs. Backward compatibility and/or partial deployment will need to be addressed in the documents defining the extensions using the TLVs. The backward compatibility problem for future extensions can't be solved here - this is about extendible encoding for the base OSPFv3 fixed format LSAs and nothing more.


>   That's why I think migration from the old-style LSA MUST be provided by the solution but solution should also define a point where backward compatibility is undesirable.
>   Something like this:
> 0). Router is sending and using in SPF old-style LSA
> 1). Router is sending both old-style and extended LSAs but using only old
> 2). Router is sending both old-style and extended LSAs but using only extended
> 3). Router is sending and using only extended LSAs
> Steps 1 and 2 are in fact option 2 from the original email and at step 3 we arrived to option 1 but with gradual migration.
> Anton
> On 06/28/2013 11:44 AM, 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.
>> 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 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