IETF Logo Mail Archive

Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling

Shraddha Hegde <shraddha@juniper.net> Tue, 13 October 2015 04:31 UTC

Return-Path: <shraddha@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 D59791B3744; Mon, 12 Oct 2015 21:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NovipUQuK87f; Mon, 12 Oct 2015 21:31:12 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC391B3207; Mon, 12 Oct 2015 21:31:12 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BY1PR0501MB1383.namprd05.prod.outlook.com (10.160.107.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Tue, 13 Oct 2015 04:30:53 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0293.007; Tue, 13 Oct 2015 04:30:53 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-two-part-metric@ietf.org" <draft-ietf-ospf-two-part-metric@ietf.org>
Thread-Topic: draft-ietf-ospf-two-part-metric : Max metric handling
Thread-Index: AdEAHKg/Cne5geJ/SzGq6c/Ed/OpoABj6wCAAPC0XHA=
Date: Tue, 13 Oct 2015 04:30:52 +0000
Message-ID: <BY1PR0501MB13812121E6BD78B9C15799B9D5300@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <BY1PR0501MB138192B8D1A44024E5BAD8D9D5370@BY1PR0501MB1381.namprd05.prod.outlook.com> <D23B45ED.34208%acee@cisco.com>
In-Reply-To: <D23B45ED.34208%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-originating-ip: [116.197.184.11]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1383; 5:qDeGo4qj/hYH1faatbDT9C4JLybyb3wbfznPZmueGutcmwAml+T/hZR3+u6ULfs32Z0WXfCm/6cJXHnozA5mz9XxpXKFJvjxXSvGwlSkFAw0ecnmgZZhZkY28YT0CCcp+ZdggG3q+gUTgwfpjWG8TA==; 24:HPX0oVlCFIxuhPafGK5fgNga+DZaBVz9ttOguyqFIFvbMFR9DGTnVFT11zLWo9FNSBhlqQBJEgZLsGTDGS7jKVQk9eKwbGUmrgCaDCKwCS0=; 20:TsNHeqz0PMJhHq0m5xMG5gD8hx/mUsmU3z4kN8L0iH75CRxDJRDeOZjz7Geelxnxy1ux9qzHOGQVvV96bSsuAw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1383;
x-microsoft-antispam-prvs: <BY1PR0501MB13838B3D0E4D4B748DC1AEFBD5300@BY1PR0501MB1383.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:BY1PR0501MB1383; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1383;
x-forefront-prvs: 07283408BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(189002)(164054003)(74316001)(97736004)(5001770100001)(122556002)(106356001)(5001960100002)(81156007)(15975445007)(105586002)(10400500002)(99286002)(19609705001)(87936001)(19580395003)(101416001)(230783001)(54356999)(19300405004)(102836002)(189998001)(33656002)(5008740100001)(86362001)(76176999)(19625215002)(2900100001)(5002640100001)(46102003)(11100500001)(77096005)(2950100001)(19580405001)(5003600100002)(2501003)(16236675004)(5007970100001)(40100003)(76576001)(64706001)(5004730100002)(92566002)(50986999)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1383; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB13812121E6BD78B9C15799B9D5300BY1PR0501MB1381_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2015 04:30:52.8363 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1383
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/nemmpUZDrt7yQq95dyaf_yE-I14>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 13 Oct 2015 04:31:16 -0000

Acee,

Yes, the metric change for the stub router scenario needs to be updated.

This draft is changing the maximum possible metric for a path between two adjacent nodes from 0xffff to oxffffffff.
This breaks the existing assumption that 0xffff is the max_metric i.e last resort metric. From operational
Perspective it’s better to mention this point explicitly  in the draft.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Thursday, October 08, 2015 3:03 PM
To: Shraddha Hegde <shraddha@juniper.net>; draft-ietf-ospf-two-part-metric@ietf.org
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,
Since RFC 2328 and RFC 5340 don’t explicitly call out the case of 0xffff, I don’t see why this should be handled. Perhaps, we should state both metric SHOULD be set to 0xffff in the stub router case.
Thanks,
Acee

From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Date: Tuesday, October 6, 2015 at 5:58 AM
To: "draft-ietf-ospf-two-part-metric@ietf.org<mailto:draft-ietf-ospf-two-part-metric@ietf.org>" <draft-ietf-ospf-two-part-metric@ietf.org<mailto:draft-ietf-ospf-two-part-metric@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: draft-ietf-ospf-two-part-metric : Max metric handling

Authors,

As per my understanding of the draft, SPF calculation uses sum of metric from the interface cost and the network to router cost advertised by the neighbor.
Handling of MAX metric is not described in the draft.  Since the metric will be sum of 2 16 bit numbers it can exceed the normal 0xffff metric value and the draft should talk about how to handle these cases.

Rgds
Shraddha

v2.23.0 | Report a Bug | By Email