[mif] prefix cost and RIO/RFC 4191

John Kaippallimalil <John.Kaippallimalil@huawei.com> Sun, 17 April 2016 23:29 UTC

Return-Path: <John.Kaippallimalil@huawei.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0B12D655 for <mif@ietfa.amsl.com>; Sun, 17 Apr 2016 16:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level:
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 FitWv3gPlDAV for <mif@ietfa.amsl.com>; Sun, 17 Apr 2016 16:29:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE76B12D1B3 for <mif@ietf.org>; Sun, 17 Apr 2016 16:29:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMM30099; Sun, 17 Apr 2016 23:29:31 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 00:29:31 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Sun, 17 Apr 2016 16:29:19 -0700
From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
To: "dthaler@microsoft.com" <dthaler@microsoft.com>, "mif@ietf.org" <mif@ietf.org>
Thread-Topic: prefix cost and RIO/RFC 4191
Thread-Index: AdGZAPbi8cp/6UEfTL2AjMzpwnslNQ==
Date: Sun, 17 Apr 2016 23:29:18 +0000
Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB7343A@dfweml501-mbb>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.142.243]
Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB7343Adfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57141C5C.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 338d96db89d90226c3226a46abb17296
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/70nhha3RiJTqf9m99nTqPjkZ7pw>
Cc: Peter McCann <Peter.McCann@huawei.com>
Subject: [mif] prefix cost and RIO/RFC 4191
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2016 23:29:38 -0000

Hi Dave,
Following up on your suggestion - in mif IETF 95 - to consider RFC 4191 /RIO values (L/M/H) for conveying dmm prefix cost (https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-03):
RIO values represent preferences for a destination route/prefix - these are preferences per router, and not per on-link prefix.

In the case of dmm-prefixcost, they are values in PIO meta data representing cost per on-link prefix (single link, and single access router).
Prefix-cost is low (preferred) at initial attachment,  and increases as the MN (mobile node) moves further away (e.g., PMIP tunnel across short, high speed backhaul may result in medium costs, and PMIP tunnel across a multiple backhaul/WAN network results in much higher costs).

RIO would not be able to represent values for such multiple on-link prefixes.
Is my understanding of RFC 4191 /the use of RIO correct?

BR,
John