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

Peter Psenak <ppsenak@cisco.com> Thu, 27 June 2013 21:43 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 8892221F9EC1 for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 14:43:09 -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 W3leHxBUOVRE for <ospf@ietfa.amsl.com>; Thu, 27 Jun 2013 14:43:05 -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 10AE121F9EBD for <OSPF@ietf.org>; Thu, 27 Jun 2013 14:43:04 -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 r5RLh2vX010536 for <OSPF@ietf.org>; Thu, 27 Jun 2013 23:43:02 +0200 (CEST)
Received: from ams-ppsenak-8716.cisco.com (ams-ppsenak-8716.cisco.com [10.55.51.199]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5RLguCL005527; Thu, 27 Jun 2013 23:42:56 +0200 (CEST)
Message-ID: <51CCB1DF.1030703@cisco.com>
Date: Thu, 27 Jun 2013 23:42:55 +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@ericsson.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se>
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4718D9D6@eusaamb101.ericsson.se>
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: Thu, 27 Jun 2013 21:43:09 -0000

Hi Acee,

yes, I have considered the complexity of (2). On the other hand (2) is 
also the most flexible one from the deployment perspective. It allows 
you to use new LSAs to advertise some new attributes for a link/prefix, 
while keeping the old LSA for what you use them today. Later when all 
routers understand the new format old LSAs can be removed.

Option (1) is not a realistic one from the deployment perspective IMHO.

thanks,
Peter


On 27.6.2013 22:53, Acee Lindem wrote:
> 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
>>>
>>
>>
>
>
>