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

Shraddha Hegde <> Tue, 13 October 2015 04:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D59791B3744; Mon, 12 Oct 2015 21:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NovipUQuK87f; Mon, 12 Oct 2015 21:31:12 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CC391B3207; Mon, 12 Oct 2015 21:31:12 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 13 Oct 2015 04:30:53 +0000
Received: from ([]) by ([]) with mapi id 15.01.0293.007; Tue, 13 Oct 2015 04:30:53 +0000
From: Shraddha Hegde <>
To: "Acee Lindem (acee)" <>, "" <>
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: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB13812121E6BD78B9C15799B9D5300BY1PR0501MB1381_"
MIME-Version: 1.0
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: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] draft-ietf-ospf-two-part-metric : Max metric handling
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Oct 2015 04:31:16 -0000


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.


From: Acee Lindem (acee) []
Sent: Thursday, October 08, 2015 3:03 PM
To: Shraddha Hegde <>;
Cc: OSPF WG List <>
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.

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


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.