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

Shraddha Hegde <shraddha@juniper.net> Tue, 20 October 2015 04:36 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 4EA021B2B90; Mon, 19 Oct 2015 21:36:14 -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 GyGIaGZJTlNN; Mon, 19 Oct 2015 21:36:07 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52E51B2B7F; Mon, 19 Oct 2015 21:36:05 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) with Microsoft SMTP Server (TLS) id 15.1.300.14; Tue, 20 Oct 2015 04:35:46 +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.0300.010; Tue, 20 Oct 2015 04:35:46 +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/OpoABj6wCAAPC0XHAAwCCHAABwceugAAopSgAAJPMn0A==
Date: Tue, 20 Oct 2015 04:35:45 +0000
Message-ID: <BY1PR0501MB138113E098ECD8686FA81D7BD5390@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <BY1PR0501MB138192B8D1A44024E5BAD8D9D5370@BY1PR0501MB1381.namprd05.prod.outlook.com> <D23B45ED.34208%acee@cisco.com> <BY1PR0501MB13812121E6BD78B9C15799B9D5300@BY1PR0501MB1381.namprd05.prod.outlook.com> <D24707EC.36BFB%acee@cisco.com> <CY1PR0501MB13852D85F51AA7821BE46751D53A0@CY1PR0501MB1385.namprd05.prod.outlook.com> <D24A3F38.36DB3%acee@cisco.com>
In-Reply-To: <D24A3F38.36DB3%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.14]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1381; 5:PAVgjD7xrjOb8FGg7XPafTkxdaonlVSayJQRxpf5yTxeRtkZnwYeEQfncNFo8VDKUVEsUyc8na48wbt7NTaLRQ9LIWXtkw8p6E0xNpdoIIuKbkRBeO5vdy1qylZGz6ilNvq0KvFtYe1TtvG9tlmg+Q==; 24:pNGdAuqweekUjNhFY/S4xgfrirI2iFmfyDt2f+Hzczju5eNo7dELA02+olmE6iiC4Z5jmK54REOVxhbMRgk7POI/wDtr9o+FUf+6vZ9mPbU=; 20:2dUV/BLCWx+BLOHdPfb1B70/j4goyPAEJScu2bPQflSlVZSyq3ChlMJvj9pjIRoGj4zImzLtMSnoPBiHddUuVg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381;
x-microsoft-antispam-prvs: <BY1PR0501MB13814BA69FDB4C43D6663C3CD5390@BY1PR0501MB1381.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)(5005006)(520078)(3002001); SRVR:BY1PR0501MB1381; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381;
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(189002)(377454003)(122556002)(87936001)(10400500002)(40100003)(99286002)(92566002)(106356001)(93886004)(5007970100001)(5001960100002)(46102003)(5002640100001)(5003600100002)(189998001)(105586002)(230783001)(33656002)(76176999)(19580405001)(77096005)(101416001)(11100500001)(66066001)(64706001)(2950100001)(2900100001)(76576001)(54356999)(102836002)(15975445007)(74316001)(97736004)(19300405004)(5004730100002)(2501003)(50986999)(86362001)(19609705001)(16236675004)(5001920100001)(19625215002)(5001770100001)(19580395003)(5008740100001)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; 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_BY1PR0501MB138113E098ECD8686FA81D7BD5390BY1PR0501MB1381_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 04:35:45.9765 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1381
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/kWAxlzAgvF1zaDILNZ6eiEd90uI>
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, 20 Oct 2015 04:36:14 -0000

Acee,

>Explain to me how it is not longer a safe last resort metric if it is greater than 0xffff? Show me a viable topology?


              8fff        10
           ---------E ---------
     8fff|                        \
D--------    8fff       10   \
|           |_____F-------G
| 10                                   \ 10
A-----------B-----------------C
       10             10



In the above topology D’s interface cost is set to 8fff. F’s network-to-router cost is also set to 8fff.

The path from A to C in normal operation is A->B->C.
Let’s say B-> C link should be replaced . Setting B->C interface cost 0xffff will not move the traffic away from that link
Since the cost  to reach C via other path is

A->D->F->G->C
 Is
10 + 8fff + 8fff + 10 + 10 + 10=  1202E

0x1202E is greater than 0xffff.

In the absence of two-part metric the cost would be 10 + 8fff +10+10+10 = 0x902f
And the traffic would be diverted.

Did I miss something? Or misunderstood the two-part metric?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Monday, October 19, 2015 4:07 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,

From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Date: Monday, October 19, 2015 at 1:53 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "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: RE: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Acee,

It was a mistake to think 0xffff added to 0xffff will make it 0xffffffff .
The metric will be 0x1fffe which is still much greater than 0xffff.

If an operator has assigned  metric of 0xffff for a link  thinking that this will be the last resort  link
Since there is no metric beyond 0xffff.
This assumption will be broken when two part metric is introduced. As there can be node-node paths with metric
Larger than oxffff, so 0xffff is no longer a safe last resort metric.

Explain to me how it is not longer a safe last resort metric if it is greater than 0xffff? Show me a viable topology?



Introducing two-part metric for broadcast links into the network has operational impact and I think it should be stated explicitly in the draft.

We will cover stub router operation in the next revision.

Thanks,
Acee


Rgds
Shraddha

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, October 17, 2015 5:36 AM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; 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: Re: draft-ietf-ospf-two-part-metric : Max metric handling

Hi Shraddha,

Even if we set both metrics to 0xffff, the link metric is 0x1FFE. This is far from 0xffffff. Hence, I don’t really understand your concern of this changing the behavior.

Thanks,
Acee

From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Date: Tuesday, October 13, 2015 at 12:30 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "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: RE: draft-ietf-ospf-two-part-metric : Max metric handling

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<mailto:shraddha@juniper.net>>; 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: 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