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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 03 October 2014 11:55 UTC

Return-Path: <zzhang@juniper.net>
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 9D7351A02F5 for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 04:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 K_5tXAH3G2ic for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 04:55:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03451A02EA for <ospf@ietf.org>; Fri, 3 Oct 2014 04:55:14 -0700 (PDT)
Received: from BY2PR05MB664.namprd05.prod.outlook.com (10.141.221.28) by BY2PR05MB760.namprd05.prod.outlook.com (10.141.224.28) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 3 Oct 2014 11:54:52 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB664.namprd05.prod.outlook.com (10.141.221.28) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 3 Oct 2014 11:54:50 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.150]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.150]) with mapi id 15.00.1044.008; Fri, 3 Oct 2014 11:54:50 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Peter Psenak <ppsenak@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric
Thread-Index: Ac+lGUvqIiqLTqfBSei7UevvhvhHhQADWYKADlJm8kAAI4XmAAAAVZRw
Date: Fri, 3 Oct 2014 11:54:49 +0000
Message-ID: <6becb8b9122147f7b5120ec5e9398762@BY2PR05MB079.namprd05.prod.outlook.com>
References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> <53CD7F3F.308@cisco.com> <18267bfa69094e108546bb9812c5ee6c@BY2PR05MB079.namprd05.prod.outlook.com> <542E8A72.30209@cisco.com>
In-Reply-To: <542E8A72.30209@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB664;UriScan:;
x-forefront-prvs: 0353563E2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(41574002)(189002)(13464003)(199003)(51704005)(479174003)(377454003)(120916001)(74316001)(107046002)(87936001)(93886004)(85306004)(230783001)(20776003)(92566001)(10300001)(122386001)(15975445006)(64706001)(99396003)(101416001)(86362001)(2656002)(15202345003)(33646002)(108616004)(76482002)(2501002)(46102003)(50986999)(97736003)(99286002)(77096002)(19580395003)(21056001)(76576001)(85852003)(80022003)(95666004)(4396001)(31966008)(66066001)(19580405001)(76176999)(54356999)(106356001)(105586002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB664; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/c2-iESMKdxxg_Q0_X49mtQhr9bg
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:55:17 -0000

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.

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
> >>>
> >
> > .
> >