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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 21 July 2014 19:25 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 []) by ietfa.amsl.com (Postfix) with ESMTP id F1E8C1A01EB for <ospf@ietfa.amsl.com>; Mon, 21 Jul 2014 12:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MtCEeMnSrI9r for <ospf@ietfa.amsl.com>; Mon, 21 Jul 2014 12:25:05 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FAC61A036F for <ospf@ietf.org>; Mon, 21 Jul 2014 12:25:02 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com ( by BY2PR05MB662.namprd05.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 19:24:59 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([]) by BY2PR05MB079.namprd05.prod.outlook.com ([]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 19:24:59 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Follow-up discussion on draft-zzhang-ospf-two-part-metric
Thread-Index: Ac+lGUvqIiqLTqfBSei7UevvhvhHhQ==
Date: Mon, 21 Jul 2014 19:24:58 +0000
Message-ID: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0279B3DD0D
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(41574002)(189002)(199002)(110136001)(81342001)(81542001)(95666004)(107046002)(229853001)(76482001)(21056001)(76576001)(31966008)(66066001)(77982001)(64706001)(74502001)(80022001)(79102001)(105586002)(74662001)(20776003)(77096002)(106356001)(86362001)(54356999)(46102001)(50986999)(99396002)(2656002)(33646002)(87936001)(4396001)(83072002)(85852003)(92566001)(2351001)(83322001)(101416001)(85306003)(74316001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB662; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ksthVACloJHTbSIPxhW5q5oTjUI
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: [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: Mon, 21 Jul 2014 19:25:08 -0000


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

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