Pete, There are no simple way to compute that prefix cost. If we say that it is just a topological distance, that’s not simple to measure either. An overlay tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud in between. We can certainly say, it can be any algorithm that presents two remote gateways/prefixes in some order with some derived cost metric, but coming out with that algorithm is the core issue here. When an access router views two sets of measurements for two distance gateways, each with different jitter, latency and packet loss characteristics, how would the AR make the call ? Would that be based on latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one definitive way to compute that, exposing the same to the end point is incorrect as that has an implication on the application that uses that prefix.
Regarding the property meta-data that goes with a prefix, it can certainly change. There is no assumption that property set does not change. A router R1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same will inform the end-point about the change in network characteristics. What goes into the meta-data is a set of properties with no ambiguity associated with it. But, here this prefix cost is about path characterization and that is not based on one factor, but its a list of factors that cannot be normalized and presented as a single value. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is “Fixed” and will always be on-link I am making a promise that cannot be kept. The MN can always move to an unaffiliated network that is unable to tunnel/route the packets to the current point of attachment. Instead of making promises about the future availability of a prefix, the best we can do is inform the MN about the current cost in terms of topological distance from the original point of assignment. The AR/network can use whatever algorithm it likes to calculate this, as long as it increases with topological distance from the original point of attachment. Some simple function of the bitwise distance between the assigned address being redirected and a new link-native prefix might suffice. The MN can use whatever algorithm it likes to release/acquire addresses, as long as the cheaper ones are more preferred over the more expensive. I don’t see any need to be more specific than that. There won’t be any interoperability issues. -Pete From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn’t) in prefix coloring . We could explore about “capabilities” in more detail - if we can do so - that could help other stds bodies understand this better also. Would like to discuss this in more detail… Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definitions for the cost metric, but it will still break the end point interoperability. If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost metric that they receive from the attached common access network ? AR needs provisioning interface to the end point and it needs policy interface to the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric for two different prefixes from two remote gateways. Its the same backhaul and the conditions/traffic patters are always changing ? With respect to end point interoperability – there needs to be an association between the network/radio link provider (PLMN), the configuration of policies of that provider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are through different providers, there will be agreements among them on consistent handling of various policies and resources – this should be one of them. With regard to changing conditions and traffic patterns – so far this draft has focused on prefix cost as a result of additional resources used due to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader applicability than just the change in prefix cost due to mobility. It could very well be that the MN does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized … If we rather acknowledge that metric definition is difficult to specify, instead we focus on capability indications. We spent few years in IETF discussing this topic of prefix coloring and may the approach is coloring is what we should look at. Just making sure I understand this: the comment is not about prefix coloring vs prefix cost (I think they are complementary), but rather that we should learn from the issues that prefix coloring draft faced. If so: – I’d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previous points …).. Regards Sri From: John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>> Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Hi Sri, This is a good point – As we note in the draft wrt policy – different service providers may configure the how the cost is interpreted by the host (see chapter 4 – Host Considerations). These could be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different set of assumptions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host is dynamically configured with S14 or OMA-DM, and the network should use the same rules to determine what prefix cost information is sent by the AR in Router Advertisements. I do agree that the draft does not explicitly say about how the network side is handled (i.e., similar to the chapter on host considerations). We can add a section like “Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the values are out of scope) – would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt 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
