IETF Logo Mail Archive

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

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

Return-Path: <acee.lindem@ericsson.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 751EA21F9D27 for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 13:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
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 1XPWjUfULIWs for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 13:53:13 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0B44221F8481 for <OSPF@ietf.org>; Thu, 27 Jun 2013 13:53:11 -0700 (PDT)
X-AuditID: c6180641-b7f5b6d000002d97-22-51cca637d170
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F1.56.11671.736ACC15; Thu, 27 Jun 2013 22:53:11 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 16:53:09 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Peter Psenak <ppsenak@cisco.com>
Thread-Topic: [OSPF] OSPFv3 LSA Extendibility - draft-acee-ospfv3-lsa-extend-00.txt
Thread-Index: AQHOc3cK9jIpbh4OU0Cj0JPpZl1KwZlJ18iA
Date: Thu, 27 Jun 2013 20:53:08 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se>
In-Reply-To: <51CCA3FE.5030505@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F21B81B302D849448B0DC2611475E550@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXSPt675sjOBBlcPqFq03LvHbrFjdzub A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxd/trxoIu4YobdxpZGhhX8ncxcnJICJhI LOv9wgRhi0lcuLeerYuRi0NI4CijxK7Pu5ghnOWMEm8frmAEqWIT0JF4/ugfM4gtIqAiMe96 DwuIzSygLPH30HowW1ggROLYzKfsEDWhEsc/roKqN5I4umM2K4jNIqAq8Xr9XDCbV8Bb4sKs LjYQm1NAU2LF1XawXkagi76fWsMEMV9c4taT+VCXCkgs2XOeGcIWlXj5+B/YHFEBPYm2Y2fY IeLKEkue7Ie6TUdiwe5PbBC2tcTOm+8ZIWxtiWULXzND3CAocXLmE5YJjOKzkKybhaR9FpL2 WUjaZyFpX8DIuoqRo7Q4tSw33chwEyMwro5JsDnuYFzwyfIQozQHi5I47wa9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKWAEXONbfIS2Xc3s9z6mvxjdniI/f43dfMlidiXEg4Cb3//VWC4 tlY3U9Di2et/O75ES81f0L5CkuXN0tXntxxwLhRRb/v5SpxZyuB/3uNG71/V//kUC87+f3WO eUey5b75dxlivDfOPr3ZiPNa7ASOhxXMqTziH55r/p98ru5JtqZY0ZKZ1uePGSixFGckGmox FxUnAgDmZMHkeQIAAA==
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: Thu, 27 Jun 2013 20:53:22 -0000

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" <ppsenak@cisco.com> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>
>

v2.23.0 | Report a Bug | By Email