[OSPF] draft-zzhang-ospf-two-part-metric

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 08 May 2014 19:33 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 10D341A00B5 for <ospf@ietfa.amsl.com>; Thu, 8 May 2014 12:33:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4CEOUlG-gqnT for <ospf@ietfa.amsl.com>; Thu, 8 May 2014 12:33:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7A1A0067 for <ospf@ietf.org>; Thu, 8 May 2014 12:32:59 -0700 (PDT)
Received: from BL2PR05MB066.namprd05.prod.outlook.com (10.255.232.19) by BL2PR05MB066.namprd05.prod.outlook.com (10.255.232.19) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 8 May 2014 19:32:54 +0000
Received: from BL2PR05MB066.namprd05.prod.outlook.com ([169.254.1.99]) by BL2PR05MB066.namprd05.prod.outlook.com ([169.254.1.99]) with mapi id 15.00.0939.000; Thu, 8 May 2014 19:32:54 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: draft-zzhang-ospf-two-part-metric
Thread-Index: Ac9qPcp5hWtufP75RPu1Q61GOV0uyA==
Date: Thu, 08 May 2014 19:32:53 +0000
Message-ID: <fd88f4ce2f6d45bba3eddd16e4709d4e@BL2PR05MB066.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 0205EDCD76
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(35774003)(74502001)(81342001)(99286001)(99396002)(50986999)(54356999)(85852003)(86362001)(74662001)(33646001)(79102001)(19580395003)(83322001)(15975445006)(81542001)(31966008)(83072002)(92566001)(101416001)(80022001)(15202345003)(4396001)(66066001)(2656002)(76576001)(85806002)(74316001)(64706001)(20776003)(77982001)(46102001)(76482001)(87936001)(21056001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB066; H:BL2PR05MB066.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
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/N35XaIDZQ_K_dOHqpoVUmJNZSG8
Subject: [OSPF] 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: Thu, 08 May 2014 19:33:03 -0000

Hi,

Finally I am getting back to this draft after the London meeting.

I believe in London we got good understanding of the problem and solution, but need further discussions on how to encode the from-network cost.

Option 1 is to encode as an MT metric (slide #9, http://www.ietf.org/proceedings/89/slides/slides-89-ospf-4.pdf). It is straightforward for IPv4, but requires Extended LSA support for IPv6.

Option 2 is to encode as Stub Link metric (slide #10). Again it is straightforward for IPv4 but for IPv6 it needs a bit more elaboration that I did not do in London (thanks for Abhay to point out that it is different for IPv6).

I am leaning toward Option 2, so that an implementation of this feature does not have to rely on the bigger changes needed for Extended LSA. Before I put the details into the draft and present it in Toronto, I'd like to outline it here to start the discussion.

Currently, RFC 5340 states that only the DR will advertise the prefixes for a transit network in the intra-area-prefix-lsa. The proposed change is to allow non-DRs to also do that, with the same reference info as the DR includes for the corresponding prefixes in its intra-area-prefix-lsa, but the metric is set to the from-network cost. For the DR itself, it also sets the metric to its from-network cost (instead of 0) in corresponding prefixes in its intra-area-prefix-lsa.

The above assumes that each router independently obtains and advertises its from-network cost. For certain networks that this feature applies to, the underlying protocol (e.g. radio control protocol for a satellite network) may be able to obtain individual from-network costs in a centralized fashion and communicate that out of band to the DR. To take advantage of that, a DR could also advertise the from-network costs for each router in its own intra-area-prefix-lsa, so that when an affecting-all event happens to cause everyone's from-network cost to change, only the DR needs to update its intra-area-prefix-lsa (to reduce the flooding of multiple intra-area-prefix-lsa).

To achieve that, when the DR examines each link-lsa associated with the link as described in 4.4.3.9 of RFC 5340, in addition to advertising a single "primary" prefix (out of duplicated ones described in the link-lsa's), different prefix entries are also advertised, with the reference info set to (0x2002, DR's Interface ID, adjacent router's RouterID). The prefix in those entries will all be the same, and the metric is set to the from-network cost.

The difference of those additional prefix entries from the "primary" one is that the Reference Advertising Router is an adjacent router but not the DR itself.

During SPF calculation, when a router vertex is reached from a network vertex, the rouer's from-network cost is determined the following way:

- Look up the intra-area-prefix-lsa advertised by the DR, and look for a matching prefix from the above additional special prefix entries.
- If not found, look up the intra-area-prefix-lsa advertised by the router, and look for prefix entry that references the corresponding network lsa.

Any prefixes in the intra-area-prefix-lsa with the Referenced Advertising Router not matching the advertiser of the intra-area-prefix-lsa will be ignored for all other purposes. They are only used to obtain the from-network cost.

Comments?

Thanks.
Jeffrey