I don’t think this is about a new option, vs an extension to existing option in some draft. I’m trying to understand the practical use for that prefix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul links and using that measurement in gateway selection appears to be a very expensive proposition and the real value of that approach is the question here. The difference in the back haul measurements between a access gateway and any gateway will be insignificant as these are high-speed pipes; the difference is always the air interface, or the application server.
We should discuss this in Yokohoma. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 29, 2015 at 11:58 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 We need more than just a binary value. Those tunnels can be long, medium, short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we reference it in the draft). I don’t think DHCP is the right protocol to carry this information. If you believe, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn’t tie the transmission of the information to the DHCP state machine. We should not force DHCP to run on every handover. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , or a remove prefix (as in this example), then its more a capability indicator and not a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more and it always converge to a binary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell what is local prefix and what is remote prefix. I’m also thinking why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties) does not help here. At least there, inherently there is an aspect of an application selecting a prefix based on its requirements and not have the network blindly assume the application requirement and select a gateway that it believes is the best for the application. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 The application should always prefer the lowest cost prefix (the more local one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a session already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt If you look at the network design of any SP’s network archtecture, they ensure the latency between two points in the back-haul network does not exceed “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway will give you prefix-cost of 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? It always coverges to local or remote, similar to the current home or roam. If there is any latency differential, that is largely due to radio or the application server, and the prefix cost does not include either of them. Fundamentally, the approach of application selecting a prefix that is based on some thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don’t know if MIF guys would have a clue about this, but 6man and Routing guys may give some sensible feedback. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 I don’t understand why you think it needs to be so complicated. It seems much simpler than the other prefix coloring approaches I have seen being suggested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can suggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong protocols. Traditionally, such aspects are managed in routing protocols, DNS layers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for CDN selection. There are sophisticated measurement techniques. There are also other query based schemes with DNS. DNS SRV records are specifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. We can certainly bring that complexity into the access gateway and into ND, and without being prescriptive on the approach, or how it even remotely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comments, but I’m not convinced this even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedback. cheers Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 An MN may not use the lowest-cost prefix because it has an ongoing session with a previously-assigned, but now higher cost, prefix. We have to leave the address release decision up to the MN because the network does not have a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multiple (inbound) routes that the MN is selecting from. The network needs to provide a hint about which prefix is the most local, direct path to the Internet. The network has the topology information, but we don’t necessarily want to send a map of the operator’s network to the MN. So, I think encapsulating this information in a single cost metric is both necessary and appropriate. -Pete From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, how will that be used is still the question ? As you said, Prefix-Cost is local to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value means its most preferred. If I’ve two apps, why will I not ever use a best cost prefix ? Does this not all finally converge to “most-preferred” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has “shorter tunnel”, but I’m afraid prefix-cost alone is not sufficient. This is about path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that I do not believe ND is the right container for presenting such data. May be this should be part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 We can’t send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn’t know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing sessions. The MN needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long tunnel and a short tunnel? They impose dramatically different costs on the network operator, and we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to the lower cost prefixes. I also don’t see the reason to expose the network mobility management scheme to the MN. Why does the MN care that it’s a tunnel being used, and not a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt I’ve not payed attention to that discussion on the fixed/sustaining/nomadic address types. But, I don’t see much relation to this specific extension around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as some number or some representation of topological distance; its not dealing with properties or capabilities and at least the draft does not talk about that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an address that has lower prefix-cost value, when there is another prefix with a better prefix-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color palette :), I don’t see an issue there. As long as you can give a property name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on the wire. These properties have well defined meaning that can be used by applications for matching the app requirement with the address capabilities. We can certainly argue that we can define infinite # number of properties (with the long/short tunnel example) and we are back in square one, but thats a name space management issue and we will not allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown and the value has no universal meaning and my point there its not helping the end point in address selection. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 Ok, now I think we are getting somewhere. I was assuming you were part of the consensus that has seemed to form around “fixed”, “sustained”, and “nomadic” as the only 3 colors. I hope we agree that those three values don’t really mean anything when sent from the network to the host. They might make sense in some kind of internal operating system API, but that’s a separate question. Now I think we are just debating the size and scope of the color pallette. In your example, you have a bit that represents “tunneling in effect”. However, there are long tunnels and there are short tunnels. A tunnel from the previous base station to the current base station, which are connected by a single Ethernet cable, is no big deal. However, a tunnel to a foreign network where the prefix was originally assigned may be using up substantial resources and may be costing the visited operator real money due to interconnection fees. I would like to be able to distinguish between these two cases. In general, the MN just wants to know “how much pain am I causing the network operator by holding on to this prefix?” The MN doesn’t need to know or care about what kind of mechanism (tunneling, routing, or carrier pigeon) is being used to direct packets destined for the IP address to his current point of attachment. He can just make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, less costly prefix. Simple administratively configured scalar values are used like this all the time in routing protocols to choose among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I will be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt > It is intended as a measure of the amount of state being maintained in the > network on behalf of this prefix and the amount of transport resources being > expended to tunnel/route the packets to the current point of attachment. This is exactly the point. We cannot represent that “state” and “resources” associated with the prefix in a single parameter called “prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local to the operator, how does my stack on the host make use of it ? I’m launching two applications and there are two prefixes P1 with P-C=5, P2/P-C=6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we never published that algorithm. What is the point ? Why not suppress all prefixes and give a single prefix that is deemed to meet the app requirement, from the AR point of view ? If we say that, we don’t specify the algorithm, keep the scope to operator’s end points and domain, then there is truly no need for interop. I think what you guys are looking for is this extension, https://tools.ietf.org/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the “fixed” comment, I see where the disconnect is and its my mistake. I meant to say, there are “n” number of properties that goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do change. Property bit A can be ON at R1, but may be OFF on R2. Your example of “Tunneled” is OFF at home link, but ON on a visitor link. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.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 So “Fixed” does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can measure those things end-to-end with transport protocols. It is intended as a measure of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachment. A prefix allocated originally by a different provider should have a high cost. A prefix allocated from another region in the same provider would have a medium cost. A prefix locally allocated by the current AR would have a minimal cost. It reflects the internal topology of the current access provider and the relationship of the current AR to the point where packets would be routed if the address were fully aggregated. We don’t have to, and we shouldn’t, standardize any algorithm for computing this value because every service provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences in BGP, and yet the protocol functions by preferring routes with lower values over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt 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
