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

Peter Psenak <ppsenak@cisco.com> Fri, 28 June 2013 13:29 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A9B21F8449 for <ospf@ietfa.amsl.com>; Fri, 28 Jun 2013 06:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8g0GnEYnupt for <ospf@ietfa.amsl.com>; Fri, 28 Jun 2013 06:29:19 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D121F8D0D for <OSPF@ietf.org>; Fri, 28 Jun 2013 06:29:18 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SDTGSW025434 for <OSPF@ietf.org>; Fri, 28 Jun 2013 15:29:16 +0200 (CEST)
Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.53]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5SDTFLP013242; Fri, 28 Jun 2013 15:29:15 +0200 (CEST)
Message-ID: <51CD8FAA.8090907@cisco.com>
Date: Fri, 28 Jun 2013 15:29:14 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Acee Lindem <acee@lindem.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE4718D71B@eusaamb101.ericsson.se> <51CD4296.1030108@cisco.com> <EF78D2C2-C0FC-4B2A-A77C-5D7A10FCCBFE@lindem.com>
In-Reply-To: <EF78D2C2-C0FC-4B2A-A77C-5D7A10FCCBFE@lindem.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "OSPF@ietf.org" <OSPF@ietf.org>
Subject: Re: [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: Fri, 28 Jun 2013 13:29:24 -0000

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,
Peter

> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
>
>