IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Sat, 17 October 2015 00:06 UTC

Return-Path: <acee@cisco.com>
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 E985B1A8846; Fri, 16 Oct 2015 17:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 WkncPKunRKby; Fri, 16 Oct 2015 17:06:47 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795A11A8822; Fri, 16 Oct 2015 17:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17803; q=dns/txt; s=iport; t=1445040404; x=1446250004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rcQLTQ2iQ278G39CQRDeoOD2UA87xVpNDuRhgJOsr08=; b=d0ss9zeCAl1WJ8lhp91+mAjOfL6PQbuKi7Pw6VVBUgDqp6j5dxVcD6QF ATz74UK+QSlSPYYdUPv5AEzFQMQJ6gCjdVGWCANQYy9KZXhsjn0wORe2n 5ob/pBWEb/rUmSVY+Qdq4OQDs7kfM4HJkKwUSoccEtHypMmfADf03gx0+ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2AQB0kCFW/4sNJK1egmhNVG8GvWsBDYFZhh4CHIEcOBQBAQEBAQEBgQqEKAEBAQQjCkwQAgEIEQMBAQEoAwICAjAUCQgCBAENBYgwsGWTCQEBAQEBAQEBAQEBAQEBAQEBAQEBARiLdYR8EQYBgmmBRQWWIgGNHIFYlk+DbgEfAQFChANyhGGBBgEBAQ
X-IronPort-AV: E=Sophos; i="5.17,691,1437436800"; d="scan'208,217"; a="42226428"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2015 00:06:38 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9H06cHj023930 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 17 Oct 2015 00:06:38 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 16 Oct 2015 19:06:22 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Fri, 16 Oct 2015 19:06:22 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, "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: AQHRAaxU3pGsXjsztkqBbWdrAPCuW55pMFsAgAW8iAA=
Date: Sat, 17 Oct 2015 00:06:22 +0000
Message-ID: <D24707EC.36BFB%acee@cisco.com>
References: <BY1PR0501MB138192B8D1A44024E5BAD8D9D5370@BY1PR0501MB1381.namprd05.prod.outlook.com> <D23B45ED.34208%acee@cisco.com> <BY1PR0501MB13812121E6BD78B9C15799B9D5300@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB13812121E6BD78B9C15799B9D5300@BY1PR0501MB1381.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: multipart/alternative; boundary="_000_D24707EC36BFBaceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Sw1zcxv4WfiSl4Ym2zKDjeSPZSE>
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: Sat, 17 Oct 2015 00:06:49 -0000

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

v2.23.0 | Report a Bug | By Email