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

Peter Psenak <ppsenak@cisco.com> Fri, 03 October 2014 12:18 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 6C1BB1A0352 for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 05:18:28 -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 NUvtWdTQUKBU for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 05:18:26 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA651A034D for <ospf@ietf.org>; Fri, 3 Oct 2014 05:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5973; q=dns/txt; s=iport; t=1412338705; x=1413548305; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RJdYgcshiRAELBI2kbUj8xdVSr9R5rb5oQrdy7Oy3ZQ=; b=iTmgo1ouAJSl7bjRoh5PwPep/lgyaDA6mz5YWXuhMUHq4rUb5jiOdw5m 5zFzdsNfmGBM0JVUh3JXMbHv4qaMLhX9+fmZimzTjZ4cj7FEm0Z91oB2S MMFp26nni4oxH4wYnapqzBc/S2q8lo8+QoYqKBuylSzzj04z8iM9c9Lyy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMEANGSLlStJssW/2dsb2JhbABgg2FYynIKh00CgSEBe4QDAQEBAwEBAQEkETYKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAQUSiBsIDb5/AReQJgcGhEUBBIYrkAWHDYEsO4MGgm+KIIN/g2U7LwGCSQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,646,1406592000"; d="scan'208";a="197711764"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Oct 2014 12:18:23 +0000
Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s93CIMp8026992; Fri, 3 Oct 2014 12:18:22 GMT
Message-ID: <542E940D.2090103@cisco.com>
Date: Fri, 03 Oct 2014 14:18:21 +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> <542E8A72.30209@cisco.com> <6becb8b9122147f7b5120ec5e9398762@BY2PR05MB079.namprd05.prod.outlook.com>
In-Reply-To: <6becb8b9122147f7b5120ec5e9398762@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/jMMiEVkCOpHyCj-SDJPIEtvGcWk
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 12:18:28 -0000

Hi Jeffrey,

On 10/3/14 13:54 , Jeffrey (Zhaohui) Zhang wrote:
> Peter,
>
> Let's say we have router A on the network. The metric from the network to A is encoded in router A's own extended LSA, so no neighbor information is needed. You can imagine that it is AS IF the metric was encoded next to the normal to-network metric side by side.

       Router A (DR)
          |
----------------------
    |          |
Router B   Router C

- what you are trying to solve is the lack of metric in A->B and A->C 
direction

- the natural choice would be for A (DR) to advertise a metric for each 
adjacent neighbor. Why do you prefer to advertise the reverse metric 
from B and C instead?

thanks,
Peter

>
> We did consider to optionally encode that in the extended network LSA for OSPFv3, so that if the underlying network has the ability for the DR to learn the from-network metric for each neighbor, then it'll be able encode those metrics in the network LSA, further reducing the churning when an affect-all event happens. That was in -02, but it was deemed too dependent on the underlying network (to let the DR know those metrics) and deviating from the normal OSPF, so it was take out.
>
> Thanks.
> Jeffrey
>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Friday, October 03, 2014 7:37 AM
>> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
>> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; tom.mcmillan@l-
>> 3com.com; Lili Wang
>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-
>> metric
>>
>> 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
>>>>>
>>>
>>> .
>>>
>
> .
>