Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric

Peter Psenak <ppsenak@cisco.com> Tue, 22 July 2014 16:03 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866B1A0302 for <ospf@ietfa.amsl.com>; Tue, 22 Jul 2014 09:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ojb9vNlcz_K for <ospf@ietfa.amsl.com>; Tue, 22 Jul 2014 09:03:37 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60781B27AD for <ospf@ietf.org>; Tue, 22 Jul 2014 09:03:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3914; q=dns/txt; s=iport; t=1406045014; x=1407254614; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8dEQrYOcGeiW6ZibhqgvMG3Py6R6hFLO9nD9yNf5fJo=; b=MB0A+bcz43ghSFb3wDo2TlF9KwhoyDfKn761UNWMQDqnjDckXyn0/X8O 0XzLZYXv60Bg1SaJM1IhYABnHdY4s5kO8lYqtrS7HLiFODOcqjzjPj7uf 14QFa1fx6BOefucQJI/YIuitDgo/Gj0ZzzlF2THuW1bZnqhnl0k6Ytq6x w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMEAFKKzlOtJssW/2dsb2JhbABYg2BXxw0Kh0UBgSd2hAMBAQEDAQEBATU2CgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgEMAQUCAQEXiB8IDb9xF49LBwaEQAEEmyaBTYVIjRqDYCEv
X-IronPort-AV: E=Sophos;i="5.01,710,1400025600"; d="scan'208";a="115261531"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 Jul 2014 16:03:32 +0000
Received: from [10.61.109.221] (dhcp-10-61-109-221.cisco.com [10.61.109.221]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6MG3Ujn012592; Tue, 22 Jul 2014 16:03:31 GMT
Message-ID: <53CE8B52.7070007@cisco.com>
Date: Tue, 22 Jul 2014 12:03:30 -0400
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "ospf@ietf.org" <ospf@ietf.org>
References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> <53CD7F3F.308@cisco.com> <75f0e1a87ea4418697308c5b4c28f94e@BY2PR05MB079.namprd05.prod.outlook.com>
In-Reply-To: <75f0e1a87ea4418697308c5b4c28f94e@BY2PR05MB079.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OW7kKDi63vgpDhLxOYMV3XxJapE
Cc: "vibhor.julka@l-3Com.com" <vibhor.julka@l-3Com.com>, "Dave.Dubois@gdc4s.com" <Dave.Dubois@gdc4s.com>, "tom.mcmillan@l-3com.com" <tom.mcmillan@l-3com.com>
Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 22 Jul 2014 16:03:39 -0000

Jeffrey,

On 7/22/14 12:00 , Jeffrey (Zhaohui) Zhang wrote:
> Hi Peter,
>
> Thanks for clarifying.
>
> Yes Extended Link LSA for OSPFv2 could be used. If we go the path of using E-Router LSA for OSPFv3, then yet another option is to go back to the MT-based encoding. That approach for OSPFv2 was documented in -00 but would not work for OSPFv3 until OSPFv3 MT is specified. With the progress of OSPFv3 LSA Extendibility work, do you have plans to resume the OSPFv3 MT work soon? If yes, using MT-based encoding would be even more consistent between OSPFv2 and OSPFv3.

I do not believe there are any plans to introduce MT to OSPfv3 at this 
point.

thanks,
Peter

>
> Anyway, the encoding mechanism can be further discussed, especially if this becomes a WG item.
>
> Thanks.
>
> Jeffrey
>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Monday, July 21, 2014 5:00 PM
>> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
>> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; tom.mcmillan@l-
>> 3com.com
>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-
>> metric
>>
>> Hi Jeffrey,
>>
>> please see inline:
>>
>>
>> On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote:
>>> Hi,
>>>
>>> In today's OSPF session there were mainly two questions/comments
>> during my presentation:
>>>
>>> 1. Acee: more discussion on mailing list about whether this is a
>> general problem/solution that the WG should be taking on
>>> 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding
>>
>> my comment was not specific to OSPFv3.
>> I propose to use following extensions to encode metric from DR to
>> attached router:
>>
>> 1. OSPFv2: Extended Link LSA
>> 2. OSPFv3: E-Router LSAs
>>
>>>
>>> I want to repeat and add some comments/answers here as a starting
>> point for more discussions on the mailing list.
>>>
>>> For #1:
>>>
>>> - The described problem is real for some large scale and mission
>> critical networks
>>> - The problem and solution are not only applicable to the above
>> mentioned example network, but also general to any broadcast network
>> that have different costs between different pair of routers. As long as
>> the router-to-router costs can be presented as a to-network and a from-
>> network part, then the simple solution applies
>>> - The two-part-metric concept is a natural extension of the SPF graph
>> theory - we're just changing the previously zero from-network cost to
>> none-zero.
>>>
>>> For #2, there are pros and cons with each approach.
>>>
>>> - The stub-link based approach does not depend on the in-progress LSA
>> Extensibility work. This has larger impact on implementation - the
>> feature can be supported w/o big changes to support extended LSA format.
>>
>> though the stub-link approach is simpler to implement, it's a bit of a
>> "hack", as you are using a standard encoding for a stub link to
>> advertise a metric for a neighbor on a broadcast link.
>>
>>> - The LSA Extensibility work is only applicable for OSPFv3. That means
>> OSPFv2 would need a different approach for the problem. Acee also
>> mentioned that it would be good to have consistent approaches between
>> OSPFv2 and OSPFv3.
>>
>> what I proposed is consistent - uses new extended LSAs in both OSPFv2
>> and OSPFv3.
>>
>> thanks,
>> Peter
>>
>>> - As a result at this time we would prefer the stub-link approach.
>>>
>>> The authors would like to hear more of your opinions/suggestions.
>> Hopefully we can reach consensus on the applicability of the problem &
>> solution so that it can become a WG item, and choose the best encoding
>> approach.
>>>
>>> Thanks!
>>> Jeffrey
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>
> .
>