John: How would the AR know the cost of a prefix ? Assuming the AR is taking the role of a access gateway and the projected prefix is from a remote gateway, how would it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some arbitrary cost metric; those capabilities in the form of attributes allow the MN to pick up a right prefix. So, I'm not sure how the AR computes this cost and how the end points make use of this value.
Sri From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>> Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submission below). The comments addressed include that from the last meeting, as well as discussions on the reflector regarding how this cost can be provided to the host: 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host. I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IETF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefixcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-mccann-dmm-prefixcost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
