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

Peter Psenak <ppsenak@cisco.com> Fri, 03 October 2014 11:37 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 BE2E61AD041 for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 04:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level:
X-Spam-Status: No, score=-15.287 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.786, 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 0ulVHjKwNm83 for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 04:37:25 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F08D1AD039 for <ospf@ietf.org>; Fri, 3 Oct 2014 04:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4060; q=dns/txt; s=iport; t=1412336245; x=1413545845; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+c3uDi1itXj4fgCAUMz08ReRkcYlZ9ApIxHXF9Vbfxo=; b=j/lm+tf2ku/I15TG0VDUUu0s5OM/AGk3QAFRCltJ5yQYnqb8jlG7iKyv twHXNa8mJ5ecf84jw1z22eg2j6zGvra9MbbcXhy3y46K1I/p7OA4/R+0d 5h3A63Eh04t/PmwndfSCfqf3tLlspMA0YaAKNwPLOR16ZxzMxZBsarZ+6 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMEAHaJLlStJssW/2dsb2JhbABgg2FYynAKh00CgSIBe4QDAQEBBAEBATU2CwwECxEEAQEBCR4HDwIWHwkIBgEMAQUCAQEFEogjDb5zAReQJgcGhEUBBJYwhw2BLDuDBoJviiCDf4NlOy8BgkkBAQE
X-IronPort-AV: E=Sophos;i="5.04,646,1406592000"; d="scan'208";a="193565168"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Oct 2014 11:37:23 +0000
Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s93BbMDX027058; Fri, 3 Oct 2014 11:37:23 GMT
Message-ID: <542E8A72.30209@cisco.com>
Date: Fri, 03 Oct 2014 13:37:22 +0200
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> <18267bfa69094e108546bb9812c5ee6c@BY2PR05MB079.namprd05.prod.outlook.com>
In-Reply-To: <18267bfa69094e108546bb9812c5ee6c@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/HPC2DTiUgLly77C5bnBj_nGnIAM
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: Fri, 03 Oct 2014 11:37:28 -0000

Jeffrey,

the encoding you proposed would not work.

OSPFv2:

- you added Network-to-Router Metric Sub-TLV in Extended Link TLV, but 
Extended Link TLV does not have any neighbor identification. Please look 
at LAN Adj-SID Sub-TLV defined in 
draft-ietf-ospf-segment-routing-extensions - you need something similar.

OSPFv3:

- you added Network-to-Router Metric Sub-TLV to Router-Link TLV of 
E-Router-LSA. That is not the right place. You should put the metric 
from DR to neighbors inside OSPFv3 E-Network-LSA and include neighbor 
identifier in it.

thanks,
Peter


On 10/2/14 20:42 , Jeffrey (Zhaohui) Zhang wrote:
> Peter, and all,
>
> I have posted a new revision, which uses the following to encode the from-network metric.
>
>> 1. OSPFv2: Extended Link LSA
>> 2. OSPFv3: E-Router LSAs
>
> http://www.ietf.org/id/draft-zzhang-ospf-two-part-metric-03.txt
>
> Please review and comment.
>
> 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
>>>
>
> .
>